WO2024124952A1 - 一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品 - Google Patents

一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品 Download PDF

Info

Publication number
WO2024124952A1
WO2024124952A1 PCT/CN2023/114284 CN2023114284W WO2024124952A1 WO 2024124952 A1 WO2024124952 A1 WO 2024124952A1 CN 2023114284 W CN2023114284 W CN 2023114284W WO 2024124952 A1 WO2024124952 A1 WO 2024124952A1
Authority
WO
WIPO (PCT)
Prior art keywords
consensus
local
block
node
main chain
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2023/114284
Other languages
English (en)
French (fr)
Inventor
王宗友
梁军
舒丽珂
蓝虎
时一防
廖志勇
刘区城
刘汉卿
黄杨峻
聂凯轩
朱耿良
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN202211637944.0A external-priority patent/CN118210853A/zh
Priority claimed from CN202211637945.5A external-priority patent/CN118214569A/zh
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to EP23902161.1A priority Critical patent/EP4568174A4/en
Priority to US18/510,310 priority patent/US12445316B2/en
Publication of WO2024124952A1 publication Critical patent/WO2024124952A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present application relates to the field of blockchain technology, and in particular to a blockchain data processing method, device, equipment, computer-readable storage medium, and computer program product.
  • the business nodes in the business network need to rely on the consensus nodes deployed in the core consensus network to perform transaction packaging and block consensus. Therefore, the business nodes deployed in the business network of a single blockchain system do not participate in block consensus themselves, but serve as a ledger synchronization tool for a single chain involved in the single blockchain system.
  • the consensus nodes e.g., packaging nodes
  • a business node e.g., business node A
  • a business node in the business network synchronizes from the single chain of the core consensus network to the corresponding block, it will not only synchronize the ledger data of transactions related to itself, but also synchronize the ledger data of transactions related to other business parties, thereby affecting the security and privacy of transaction data on the chain.
  • the embodiments of the present application provide a blockchain data processing method, apparatus, device, computer-readable storage medium, and computer program product, which can improve the security and privacy of on-chain transaction data.
  • the embodiment of the present application provides a blockchain data processing method, which is executed by a local consensus node in a local consensus network, wherein the local consensus network is deployed in a business network of a multi-layer chain network, and a core consensus network independent of the business network is also deployed in the multi-layer chain network, wherein the core consensus network includes a core consensus node; the method includes:
  • the local consensus transaction, the main chain binding height and the main chain read data set are packaged into a local consensus block, wherein the local consensus transaction refers to a business transaction executed in the local consensus network, and the main chain binding height is the block height of the first global consensus block, which is obtained from the core consensus when packaging the local consensus transaction.
  • the main chain read data set is synchronized to the main chain of the identification node, the main chain read data set is cleared from the first global contract state and is used to execute the local consensus transaction, and the first global contract state is the read data set read when executing the global consensus transaction in the first global consensus block;
  • the local verification node Broadcasting the local consensus block to the local verification node, the local verification node is used to obtain the voting consensus result corresponding to the transaction execution result of the local consensus transaction when the synchronized block height is greater than or equal to the main chain binding height and the synchronized read data set is consistent with the main chain read data set, and the local verification node is a consensus node in the local consensus network other than the local consensus node;
  • the local consensus block is chained to the local consensus subchain corresponding to the local consensus network, and the local consensus block is written into the local consensus ledger database.
  • the embodiment of the present application provides a blockchain data processing method, which is executed by a core consensus node in a core consensus network; the core consensus network is deployed in a multi-layer chain network; a business network independent of the core consensus network in the multi-layer chain network is deployed with a local consensus network, and the local consensus network includes a local consensus node, and the method includes:
  • the main chain synchronization request carries the block height of a third global consensus block
  • the third global consensus block is a global consensus block synchronized from the main chain by the local consensus node before synchronizing to the first global consensus block
  • the first global contract state is a set of read data read when executing a global consensus transaction in the first global consensus block;
  • the first global consensus block and the first global contract state are returned to the local consensus node, and the local consensus node is used to package the local consensus transaction, the main chain binding height and the main chain read data set into a local consensus block based on the block height of the first global consensus block and the first global contract state, and when a consensus is reached on the local consensus block based on the local consensus network, the local consensus block is chained to the local consensus network.
  • the embodiment of the present application provides a first blockchain data processing device, which runs on a local consensus node in a local consensus network, wherein the local consensus network is deployed in a business network of a multi-layer chain network, wherein a core consensus network independent of the business network is also deployed in the multi-layer chain network, wherein the core consensus network includes a core consensus node, and wherein the first blockchain data processing device includes:
  • a packaging module configured to package a local consensus transaction, a main chain binding height, and a main chain read data set into a local consensus block, wherein the local consensus transaction refers to a business transaction executed in the local consensus network, the main chain binding height is the block height of a first global consensus block, the first global consensus block is synchronized from the main chain of the core consensus node when packaging the local consensus transaction, the main chain read data set is cleared from a first global contract state and is used to execute the local consensus transaction, and the first global contract state is a read data set read when executing a global consensus transaction in the first global consensus block;
  • a consensus module configured to broadcast the local consensus block to a local verification node, wherein the local verification node is used to obtain a voting consensus result corresponding to a transaction execution result of the local consensus transaction when the synchronized block height is greater than or equal to the main chain binding height and the synchronized read data set is consistent with the main chain read data set, and the local verification node is a consensus node other than the local consensus node in the local consensus network;
  • the processing module is configured to, when it is determined that a consensus is reached based on the voting consensus result returned by the local verification node, chain the local consensus block to the local consensus subchain corresponding to the local consensus network, and write the local consensus block into the local consensus ledger database.
  • the embodiment of the present application provides a second blockchain data processing device, which runs on a core consensus node in a core consensus network, and the core consensus network is deployed in a multi-layer chain network; the business network in the multi-layer chain network is deployed with a local consensus network, and the local consensus network is constructed by a core consensus node in the core consensus network that is independent of the business network; the second blockchain data processing device includes:
  • An acquisition module is configured to acquire a main chain synchronization request sent by a local consensus node, wherein the main chain synchronization request carries a block height of a third global consensus block;
  • the third global consensus block is a global consensus block synchronized from the main chain by the local consensus node before synchronizing to the first global consensus block;
  • a determination module is configured to determine, from the main chain, a global consensus block whose block height is greater than the block height of the third global consensus block as a first global consensus block that has not been synchronized to the local consensus node;
  • the acquisition module is further configured to acquire a first global contract state of the first global consensus block from the main chain;
  • the first global contract state is a set of read data read when executing a global consensus transaction in the first global consensus block;
  • a data return module is configured to return the first global consensus block and the first global contract state to the local consensus node, and the local consensus node is used to package the local consensus transaction, the main chain binding height and the main chain read data set into a local consensus block based on the block height of the first global consensus block and the first global contract state, and when a consensus is reached on the local consensus block based on the local consensus network, the local consensus block is chained to the local consensus network.
  • An embodiment of the present application provides an electronic device for blockchain data processing, the electronic device including a memory and a processor, the memory being connected to the processor, the memory being used to store a computer program, and the processor being used to call the computer program so that the electronic device executes the blockchain data processing method applied to a local consensus node provided in the embodiment of the present application, or so that the electronic device executes the blockchain data processing method applied to a core consensus node provided in the embodiment of the present application.
  • An embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored.
  • the computer program is loaded and executed by a processor so that an electronic device executes the blockchain data processing method applied to a local consensus node provided in an embodiment of the present application, or so that an electronic device executes the blockchain data processing method applied to a core consensus node provided in an embodiment of the present application.
  • An embodiment of the present application provides a computer program product, which includes a computer program or computer executable instructions.
  • the computer program or computer executable instructions are executed by a processor, the blockchain data processing method applied to a local consensus node provided in the embodiment of the present application is implemented, or the blockchain data processing method applied to a core consensus node provided in the embodiment of the present application is implemented.
  • the local consensus block to be on-chain can establish an association relationship with the main chain through the main chain binding height and the main chain read data set, and perform block consensus through the local consensus block and the local verification node in the local consensus network, and when it is determined that the block consensus is reached, the local consensus block is on-chain to the local consensus sub-chain, and the local consensus block is written to the local consensus ledger database independent of the main chain sub-ledger database.
  • the block consensus of the local consensus block can be achieved in the local consensus network, and the local consensus block that has reached the block consensus can be written into the local consensus ledger database.
  • the transaction data involved in the transactions executed in the local consensus network can be stored in the associated local consensus sub-chain to achieve hierarchical independent management of the transaction data of the business transactions of each business party, and achieve the isolation of different business data, thereby improving the security and privacy of on-chain transaction data.
  • FIG1 is a schematic diagram of the architecture of a multi-layer chain network provided in an embodiment of the present application.
  • FIG2 is a schematic diagram of a block consensus scenario based on a local consensus network provided in an embodiment of the present application
  • FIG3 is a flow chart of a blockchain data processing method provided in an embodiment of the present application.
  • FIG4 is a schematic diagram of a proposed block provided in an embodiment of the present application.
  • FIG5 is a schematic diagram of a data review scenario provided in an embodiment of the present application.
  • FIG6a is a schematic diagram of a blockchain framework based on a multi-layer chain network provided in an embodiment of the present application
  • FIG6b is a schematic diagram of another blockchain framework based on a multi-layer chain network provided in an embodiment of the present application.
  • FIG7 is a flowchart of a blockchain data processing method provided in an embodiment of the present application.
  • FIG8 is a schematic diagram of an interaction of a block consensus provided by an embodiment of the present application.
  • FIG9 is a flow chart of a blockchain data processing method provided in an embodiment of the present application.
  • FIG10 is a schematic diagram of a hierarchical structure of a blockchain network
  • FIG11 is a schematic diagram of the structure of a multi-layer blockchain network provided in an embodiment of the present application.
  • FIG12 is a schematic diagram of the structure of a local consensus node provided in an embodiment of the present application.
  • FIG13 is a flow chart of a multi-layer blockchain data processing process provided by an embodiment of the present application.
  • FIG14 is a flow chart of a multi-layer blockchain data processing method provided in an embodiment of the present application.
  • FIG15 is a schematic diagram of a process of archiving account data according to an embodiment of the present application.
  • FIG16 is a flow chart of a ledger data archiving process provided in an embodiment of the present application.
  • FIG17 is a flow chart of a ledger data archiving process provided in an embodiment of the present application.
  • FIG18 is a flow chart of a multi-layer blockchain data processing method provided in an embodiment of the present application.
  • FIG19 is a flow chart of a multi-layer blockchain data processing method provided in an embodiment of the present application.
  • FIG20 is a schematic diagram of the structure of a blockchain data processing device provided in an embodiment of the present application.
  • FIG21 is a schematic diagram of the structure of a blockchain data processing device provided in an embodiment of the present application.
  • FIG22 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application.
  • Figure 23 is a schematic diagram of a blockchain data processing system provided in an embodiment of the present application.
  • FIG. 1 is a schematic diagram of the architecture of a multi-layer chain network provided in an embodiment of the present application.
  • the multi-layer chain network architecture can be applied to a blockchain-based data system (hereinafter referred to as a blockchain system), such as a blockchain electronic bill system.
  • the blockchain network corresponding to the blockchain data system can be a multi-layer chain network, which includes a business network and a core consensus network, the business network is in a public network, and the core consensus network is in a private network (for example, a private cloud); in addition, one or more independent local consensus networks can be deployed in the business network.
  • the local consensus network in the business network can be represented as the local consensus network 100a, 100b, ... shown in FIG. 1 , only two local consensus networks are exemplified here, and the number of local consensus networks is not limited here, and the core consensus network can be represented as the core consensus network 200a shown in FIG. 1 .
  • local consensus network 100a In the local consensus network 100a shown in FIG1 , multiple local consensus nodes are deployed, and local consensus nodes 10a, 10b, 10c, and 10d are exemplarily shown.
  • the number of local consensus nodes deployed in the local consensus network 100a is not limited here. As business needs change, the number of local consensus nodes can change continuously.
  • the local consensus nodes in the local consensus network 100a have a block consensus function and can maintain a local consensus subchain associated with the local consensus network 100a.
  • the blockchain jointly maintained by multiple local consensus nodes in the local consensus network 100a is a local consensus subchain 10e.
  • the business network also includes one or more local business nodes that have a network connection relationship with the local consensus network 100a, and local business nodes 30a, 30b, 30c, 30d, 30e, 30f, 30g, ..., 30n are exemplarily shown.
  • the number of local business nodes is not limited here.
  • the local consensus subchain in the local consensus network 100a is a blockchain independently managed by business party A, and the local business node that has a network connection relationship with the local consensus network 100a is the local business node corresponding to business party A.
  • the local business node that has a network connection relationship with the local consensus network 100a can submit pending business transactions (such as business transaction A) to the local consensus node in the local consensus network 100a, and the local consensus node in the local consensus network 100a packages the business transaction A into the local consensus block A; finally, after reaching a block consensus for the local consensus block A in the local consensus network 100a, the local consensus node in the local consensus network 100a links the local consensus block A to the local consensus subchain 10e.
  • business transactions such as business transaction A
  • the local consensus network 100b shown in FIG1 multiple local consensus nodes are deployed, and local consensus nodes 11a, 11b, 11c, and 11d are exemplarily shown.
  • the number of local consensus nodes deployed in the local consensus network 100b is not limited here. As business needs change, the number of local consensus nodes can change continuously.
  • the local consensus nodes in the local consensus network 100b have a block consensus function and can maintain a local consensus subchain associated with the local consensus network 100b.
  • the blockchain jointly maintained by multiple local consensus nodes in the local consensus network 100b is a local consensus subchain 11e.
  • the business network also includes one or more local business nodes that have a network connection relationship with the local consensus network 100b, and local business nodes 31a, 31b, 31c, 31d, 31e, 31f, 31g, ..., 31n are exemplarily shown.
  • the number of local business nodes is not limited here.
  • the local consensus subchain in the local consensus network 100b is a blockchain independently managed by business party B, and the local business node that has a network connection relationship with the local consensus network 100b is the local business node corresponding to business party B.
  • the local business node that has a network connection relationship with the local consensus network 100b can submit pending business transactions (such as business transaction B) to the local consensus node in the local consensus network 100b, and the local consensus node in the local consensus network 100b packages the business transaction B into the local consensus block B; finally, after reaching a block consensus on the local consensus block B in the local consensus network 100b, the local consensus node in the local consensus network 100b links the local consensus block B to the local consensus subchain 11e.
  • business transactions such as business transaction B
  • the core consensus network 200a as shown in FIG1 , multiple core consensus nodes are deployed, and core consensus nodes 20a, 20b, 20c, and 20d are exemplarily shown.
  • the number of core consensus nodes deployed in the core consensus network 200a is not limited here, and the number of core consensus nodes can change continuously as business needs change.
  • the blockchain jointly maintained by multiple core consensus nodes in the core consensus network 200a is the main chain 20e. It is understandable that the local consensus nodes in each local consensus network can synchronize the global consensus block on the main chain from the main chain. It is understandable that the local consensus network is created through the core consensus node.
  • the business object (such as the business party) can send a registration transaction and a configuration transaction for the local consensus subchain to the core consensus node to activate the local consensus network, and enable the creation of the genesis block in the local consensus subchain on the local consensus node to start the local consensus subchain, thereby completing the creation of the local consensus network and the local consensus subchain.
  • the local consensus node is the global business node corresponding to the core consensus node.
  • the local consensus node can not only synchronize the data on the main chain through the core consensus node, but also generate business transactions and send them to the core consensus node.
  • the local consensus node can perform transaction aggregation processing on the transaction execution results corresponding to the local consensus transactions in the local consensus network, obtain transaction aggregation information, and generate an information chain transaction carrying the transaction aggregation information, and finally send the information chain transaction to the core consensus node, which writes the information chain transaction to the main chain.
  • the business transactions processed in the core consensus network are called global consensus transactions
  • the business transactions processed in the local consensus network are called local consensus transactions.
  • Global consensus transactions and local consensus transactions can be different.
  • the consensus mechanism for local consensus blocks extracted by the embodiment of the present application is used to realize the consensus and chain of local consensus blocks in the local consensus network, so as to realize that some global consensus transactions that can only be processed by core consensus nodes in the core consensus network are moved to the local consensus network and executed by local consensus nodes; that is, the global consensus transactions moved to the local consensus network are used as local consensus transactions, and the transaction data involved in the local consensus transaction is written into the local consensus subchain; in this way, not only the security of transaction data involved in local consensus transactions can be improved, but also the business processing load can be shared by the local consensus network for the core consensus network, reducing the data confusion and stability on the main chain.
  • the set of read data required to be read when executing local consensus transactions can be partly from the data cleared from the main chain, such as the local consensus node can clear the global contract status data from the main chain, and the global contract status data can refer to the set of read data read when calling the global consensus on the main chain to execute the global consensus transaction. Therefore, when executing local consensus transactions, the data on the main chain can be referenced to reuse the contract status data on the main chain.
  • the core consensus node is used to reach a consensus in the core consensus network where the corresponding main chain is located, and the local consensus node is used to reach a consensus in the local consensus network where the corresponding local consensus subchain is located.
  • the core consensus network or any local consensus network has the same principle of writing the transaction data involved in the business transaction into the corresponding blockchain account book (for example, a distributed database).
  • the process of writing the transaction data in the local consensus network into the corresponding blockchain account book can be that the client sends the transaction data to a local business node, and then the transaction data is passed between the local business nodes in the local consensus network in a relay manner until the designated local consensus node in the local consensus network (for example, the local consensus node 10a in the local consensus network 100a) receives the transaction data.
  • the local consensus node packs the transaction data into a block so that it can be used for subsequent block consensus with other local consensus nodes, so that after the block consensus is passed, the local consensus block that has passed the consensus can be written into the distributed database of the local consensus network (for example, the local consensus network 100a) where it is located.
  • blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm, which is used to organize data in chronological order and encrypt it into a ledger to make it impossible to be tampered with or forged, and can also verify, store and update data.
  • a decentralized database each node in the database stores the same blockchain, and the blockchain network divides the nodes into core nodes and light nodes (such as SPV nodes); wherein the core node is used to reach a consensus on the entire blockchain network, that is, the core node is a consensus node in the blockchain network.
  • the process of writing transaction data into an account book (e.g., a local account book) in a blockchain network includes: the client sends the transaction data to the light node, and then the transaction data is passed between the light nodes in the blockchain network in a relay manner until the consensus node receives the transaction data, and the consensus node then packs the transaction data into a block so that it can be subsequently reached with other consensus nodes.
  • the consensus is passed, at least one block carrying the transaction data can be written to the distributed database in parallel through the storage layer, which can break through the limitations of the blockchain structure of the blockchain from the root, and can effectively improve the storage efficiency of data storage.
  • the consensus node in the core consensus network is a core consensus node (the core consensus node 20a in the core consensus network 200a shown in Figure 1).
  • the consensus nodes in the local consensus network are both core nodes with block consensus capabilities in the local consensus network and light nodes in the business network that can clear transaction data from the main chain (as shown in the local consensus node 11a in the local consensus network 100b in Figure 1).
  • the blockchain system can include smart contracts, which are a kind of code executed by each node (including consensus node) of the blockchain system in the blockchain system, and any logic can be executed and the result can be obtained through the smart contract.
  • smart contracts which are a kind of code executed by each node (including consensus node) of the blockchain system in the blockchain system, and any logic can be executed and the result can be obtained through the smart contract.
  • the smart contract deployed on the blockchain in response to the transaction service request, the smart contract deployed on the blockchain is called, and then the data node or light node on the blockchain can send the transaction service request to the consensus node to call the smart contract running in each consensus node to execute the transaction service.
  • the blockchain can include one or more smart contracts, which can be distinguished by the contract call address, contract identification number (Identity Document, ID) or contract name, and the transaction service request initiated by the client can also carry the contract call address or contract identification number or contract name of the smart contract to specify the smart contract to be run.
  • the smart contract specified by the client is a contract that needs to read data (i.e., a business contract)
  • each consensus node will give priority to accessing the local cache in the storage layer to read the data.
  • each consensus node will verify whether the transaction execution results are consistent with each other (that is, reach a consensus).
  • the transaction execution results can be stored in their respective local caches and local storages, and the transaction execution results of the above-mentioned transaction business can be returned to the client.
  • the local cache here is the system memory created in the storage layer
  • the local storage here is the hard disk space created in the storage layer for data storage. In this way, when a consensus node goes down or the system fails, the data in the system memory will not disappear, which will cause the phenomenon of being unable to read the data. That is, the consensus node can also read the data through the local storage in the storage layer.
  • any two blockchain nodes in any consensus network can form a peer-to-peer (P2P) network, and the peer-to-peer network can adopt the P2P protocol, wherein the P2P protocol is an application layer protocol running on the Transmission Control Protocol (TCP) protocol.
  • P2P protocol is an application layer protocol running on the Transmission Control Protocol (TCP) protocol.
  • TCP Transmission Control Protocol
  • any device such as a server, a terminal, etc. can join and become a blockchain node, wherein each blockchain node can include a hardware layer, an intermediate layer, an operating system layer, and an application layer.
  • the embodiment of the present application can bind a blockchain node to any type of business party (for example, any individual user, any enterprise, any institution, etc.) that accesses the blockchain network, so that the blockchain network composed of these blockchain nodes is collectively referred to as a consortium chain network. Therefore, the local consensus nodes 10a, 10b, etc. shown in Figure 1 can have a one-to-one correspondence with the corresponding business parties (i.e., the entity objects in the corresponding business scenarios) to be connected to the consortium chain network.
  • the business scenarios here can include electronic bill scenarios, social scenarios, etc.
  • the target business in the corresponding business scenario may specifically include electronic bill business, social business, credit business, credit business, etc., and the specific businesses in the corresponding business scenario will not be listed one by one here. Therefore, the embodiment of the present application can be applied to any business scenario where a blockchain network can be deployed, and the above-mentioned blockchain data system can also be adapted to the business scenario of a specific application.
  • the business transactions executed on the local consensus network and the business parties initiating the business transactions may be different. That is, the local consensus network can be created based on different types of business parties. For example, the business parties can be divided according to the region, and the business parties in different regions access the local consensus networks corresponding to their respective regions. For example, the main chain can be used to store transaction data related to the national bill business.
  • the business party in region A can access the local consensus network A corresponding to region A to perform bill business transactions related to region A in the local consensus network A (such as performing bill lottery business related to region A in region A).
  • the local consensus subchain in the local consensus network A can be used to store transaction data related to the bill business of region A; the business party in region B can access the local consensus network corresponding to region B to perform bill business transactions related to region B in the local consensus network (such as performing bill lottery business related to region B in region B).
  • the local consensus subchain in the local consensus network B can be used to store transaction data related to the bill business of region B.
  • a local consensus subchain independent of the main chain and dedicated to serving various business parties can be built for various business parties.
  • Business transactions related to each business party can be conducted in the local consensus networks corresponding to each business party, and the transaction data involved in the business transactions related to each business party can be packaged and uploaded to the local consensus sub-chain associated with each business party, so as to achieve the security, privacy and data isolation of transaction data.
  • Figure 2 is a schematic diagram of a block consensus scenario based on a local consensus network provided by an embodiment of the present application.
  • a consensus mechanism for local consensus blocks is proposed.
  • a block consensus for local consensus blocks that are different from the global consensus blocks on the main chain can be achieved in the local consensus network, and after reaching a block consensus, the block is chained, so that the local consensus network has a local consensus subchain that is different from the main chain, and the local consensus blocks on the local consensus subchain are associated with the main chain, so as to facilitate the management of the local consensus subchain by the main chain.
  • the local consensus node proposed in the embodiment of the present application can be any local consensus node in Figure 1 (such as the local consensus node 10a in the local consensus network 100a, or the local consensus node 10b, or the local consensus node 10c).
  • the block consensus and chain-up process of the local consensus block can be: the local consensus node obtains the cached local consensus transaction from the transaction pool to package the obtained local consensus transaction into the proposed block.
  • the main chain binding height and the main chain read data set can be obtained from the main chain sub-ledger database of the local consensus node, and the main chain binding height and the main chain read data set, as well as the local consensus transaction, are packaged into the proposed block.
  • the proposed block containing the main chain binding height, the main chain read data set and the local consensus transaction can be used as the local consensus block to be consensused.
  • the local consensus block is broadcast to the local verification nodes in the local consensus network.
  • the local verification node can audit the main chain binding height and the main chain read data set in the local consensus block, and when the data audit is successful, it can vote on the transaction execution result obtained by executing the local consensus transaction to obtain the voting consensus result.
  • the local consensus node receives the voting consensus result returned by the local verification node. When it is determined that the block consensus is reached based on the voting consensus result, it indicates that the consensus process of the local consensus block is completed.
  • the local consensus block can be chained to the maintained local consensus sub-chain, and the local consensus block can be written into the local consensus ledger database independent of the main chain sub-ledger database.
  • the main chain read data set refers to the data that needs to be read from the main chain when executing local consensus transactions.
  • the global contract status of the global consensus business contract For example, the global contract status of the global consensus business contract.
  • the local consensus block can be associated with the main chain, so that the main chain read data set can be referenced when executing the local consensus transaction in the local consensus block, and the main chain binding height enables each consensus node (that is, the local consensus node and the local verification node) to verify the consistency of the main chain read data set when performing data audit on the main chain read data set, so as to ensure that the transaction execution results of the local consensus transaction executed based on the main chain read data set are consistent.
  • the process of block consensus can be: data auditing of the main chain binding height and the main chain read data set in the local consensus block, executing the local consensus transaction in the local consensus block to obtain the transaction execution result when the data audit is successful, and mutually verifying the transaction execution results obtained by each consensus node (that is, the block consensus result) with other consensus nodes, when it is determined that there are a certain number of consensus nodes that have obtained transaction execution results that are consistent with the transaction execution results obtained by itself, generating a voting consensus result indicating that the transaction results are consistent (that is, performing voting consensus), when receiving the voting consensus results returned by other consensus nodes, and determining that there are a certain number of voting consensus results in the current voting consensus results that indicate that the transaction results are consistent, it is determined that the block consensus is reached, and
  • the local consensus node 10a uses the transaction execution result obtained by executing the local consensus transaction as the first transaction result, and obtains the transaction execution results obtained by the local consensus nodes 10b to 10d, and uses the transaction execution results obtained by the local consensus nodes 10b to 10d as the second transaction result.
  • the first transaction result and the second transaction result are compared. If it is determined that there are a certain number of second transaction results that are the same as the first transaction result, it means that the transaction execution results are consistent. At this time, a voting consensus result indicating a vote in favor is generated.
  • the local consensus node 10a obtains the voting consensus results obtained by the local consensus nodes 10b to 10d. If the number of results indicating a vote in favor among the voting consensus results obtained by the local consensus nodes 10a to 10d reaches a certain number, it means that a block consensus has been reached.
  • each local consensus node when it is conducting block consensus, it will not only conduct data review on the main chain binding height and the main chain read data set, but also vote on the transaction execution results, and determine whether to reach a block consensus based on the voting consensus results obtained and received by itself.
  • the local consensus nodes 10b, 10c and 10d are local verification nodes; and for the local consensus node 10b, the local consensus nodes 10a, 10c and 10d are local verification nodes; and for the local consensus node 10c, the local consensus nodes 10b, 10a and 10d are local verification nodes; and for the local consensus node 10d, the local consensus nodes 10b, 10c and 10a are local verification nodes; local consensus nodes 10a-10d will all vote on the local consensus nodes in the local consensus nodes.
  • the main chain binding height and the main chain read data set are used for data audit, and when the data audit is successful, the transaction execution result obtained by executing the local consensus transaction (the transaction execution result refers to the block consensus result obtained by performing block consensus on the local consensus block) is voted on to obtain the voting consensus result, and the voting consensus result is sent to the remaining local consensus nodes respectively (for example, the local consensus node 10a sends the voting consensus result to the local consensus nodes 10b to 10d).
  • the local consensus nodes 10a to 10d will determine whether the block consensus is reached based on their own voting consensus results and the received voting consensus results, and when it is determined that the block consensus is reached, the local consensus block will be put on the chain to realize the construction of the local consensus sub-chain.
  • the local consensus node may include: local sub-chain consensus RPC (Re mote Procedure Call, remote procedure call) component 2-1, local sub-chain consensus component 2-2, local chain transaction execution component 2-3, local consensus ledger database 2-4, main chain consensus RPC component 2-5, main chain forwarding and chaining component 2-6, main chain clearing and synchronization component 2-7, main chain contract status reading component 2-8, main chain sub-ledger database 2-9.
  • the local consensus node includes two parts (part 1 corresponds to 2-1 to 2-4 shown in Figure 2, and part 2 corresponds to 2-5 to 2-9 shown in Figure 2).
  • Part 1 is used to receive local consensus transactions, package local consensus transactions into local consensus blocks, and perform block consensus and chaining on local consensus blocks;
  • Part 2 is used to synchronize the main chain data, and clear the main chain data related to itself from the synchronized main chain data (such as the global contract state required to be referenced from the main chain when executing local consensus transactions), and can also generate business transactions that need to be executed by the main chain and forward them to the chain.
  • the local consensus ledger database 2-4 and the main chain sub-ledger database 2-9 are independent of each other.
  • the local consensus node 10a can synchronize the global consensus block on the main chain and the global contract state associated with the global consensus block from the core consensus node in the core consensus network 200a (for example, any one of the core consensus node 20a, core consensus node 20b, core consensus node 20c and core consensus node 20d) through the main chain clearing synchronization component 2-7, and write the synchronized main chain data into the main chain sub-ledger database 2-9.
  • the core consensus node in the core consensus network 200a for example, any one of the core consensus node 20a, core consensus node 20b, core consensus node 20c and core consensus node 20d
  • the local consensus node 10a can synchronize the main chain through the core consensus node 20c in the core consensus network 200a; when the local consensus node 10a generates a business transaction to be uploaded to the main chain, it can trigger the main chain consensus RPC component 2-5 to call the main chain forwarding component 2-6 to forward the business transaction to be uploaded to the main chain to the core consensus node 20c, and the core consensus node 20c writes the business transaction received from the main chain forwarding component 2-6 to the main chain.
  • the main chain consensus RPC component 2-5 can perform transaction verification on the business transaction to be uploaded to the main chain, and call the main chain forwarding component 2-6 through the main chain consensus RPC component 2-5 to forward the verified business transaction to the core consensus node 20c.
  • the local consensus node 10a when receiving a local consensus transaction, can call the local sub-chain consensus RPC component 2-1 to verify the local consensus transaction and put it into the transaction pool, and call the local sub-chain consensus component 2-2 through the local sub-chain consensus RPC component 2-1 to obtain the cached local consensus transaction from the transaction pool, and the local sub-chain consensus component 2-2 will package the obtained local consensus transaction into the proposal block.
  • the main chain contract state number reading component 2-8 can be called through the local sub-chain consensus component 2-2 to obtain the main chain binding height and the main chain read data set from the main chain sub-ledger database 2-9, and the local sub-chain consensus component 2-2 will package the obtained main chain binding height and the main chain read data set into the proposal block.
  • the proposal block is the local consensus block to be agreed upon.
  • the local consensus block is state-bound with the main chain through the main chain binding height, and the main chain is referenced by the main chain read data set.
  • the local sub-chain consensus component 2-2 performs block consensus on the local consensus block
  • the local consensus block can be broadcast to the local verification nodes (such as local consensus nodes 10b to 10d) in the local consensus network, so that the local consensus node 10a and the local consensus nodes 10b to 10d can vote on the local consensus block.
  • the local consensus node 10a can perform data audit on the main chain binding height and the main chain read data set in the local consensus block through the local sub-chain consensus component 2-2, and perform block consensus on the local consensus block to obtain the block consensus result when the data audit is successful, and perform voting consensus based on the block consensus result to obtain the voting consensus result.
  • the local consensus node 10a can receive the voting consensus result returned by the local consensus nodes 10b to 10d, and when it is determined that the block consensus is reached based on its own voting consensus result and the voting consensus result returned by the local consensus nodes 10b to 10d, the local consensus block is chained to the local consensus sub-chain corresponding to the local consensus network, and the local consensus block is written into the main chain sub-ledger database 2-9, for example, the local sub-chain consensus component 2-2 can write the local consensus block into the main chain sub-ledger database 2-9, or the local chain transaction execution component 2-3 can write the local consensus block into the main chain sub-ledger database 2-9. It can be understood that if the data audit is unsuccessful, the execution of block consensus on the local consensus block is terminated. The subsequent process of identification.
  • the local consensus node 10a performs block consensus on the local consensus block to obtain the block consensus result, including: calling the local chain transaction execution component 2-3 through the local sub-chain consensus component 2-2 to execute the local consensus transaction in the local consensus block to obtain the transaction execution result, and using the transaction execution result as the block consensus result.
  • the local chain transaction execution component 2-3 executes the local consensus transaction, it can call the local consensus business contract to read the main chain read data set in the local consensus block, and execute the local consensus transaction through the read main chain read data set to achieve data reference for the main chain.
  • the local consensus node 10a can mutually verify with other local consensus nodes through the local sub-chain consensus component 2-2 whether the block consensus results are consistent (for example, whether there are a certain number of block consensus results that are the same as the block consensus results obtained by the local consensus node 10a, if so, it means that a consensus is reached), if a consensus is reached, a voting consensus result indicating a vote in favor is generated, and if a consensus is not reached, a voting consensus result indicating a vote against is generated.
  • the core consensus nodes and local consensus nodes involved in the embodiments of the present application may be electronic devices, which may be independent physical servers, or server clusters or distributed systems composed of multiple physical servers. They may also be cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.
  • cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.
  • a prompt interface or pop-up window may be displayed.
  • the prompt interface or pop-up window is used to prompt the business object that it is currently collecting data such as invoice assets, and after obtaining the confirmation operation of the business object on the prompt interface or pop-up window, the relevant steps of data acquisition are started, otherwise it ends.
  • business data of users and other business objects may be involved (for example, when executing local consensus transactions in local consensus blocks, depending on the local consensus transactions, it may involve the need to obtain invoicing information, credit information, tax refund information, the company's income and expenditure, corporate qualifications and other information).
  • local consensus transactions in local consensus blocks, depending on the local consensus transactions, it may involve the need to obtain invoicing information, credit information, tax refund information, the company's income and expenditure, corporate qualifications and other information.
  • the following describes the process of block consensus on local consensus blocks in a local consensus network.
  • FIG. 3 is a flow chart of a blockchain data processing method provided by an embodiment of the present application.
  • the method can be executed by a local consensus node in the local consensus network mentioned above.
  • the local consensus node can be any local consensus node in the local consensus network 100a shown in FIG. 1 .
  • the method includes the following steps S301 to S303, and each step is described below.
  • the local consensus transaction refers to the business transaction executed in the local consensus network.
  • the main chain binding height is the block height of the first global consensus block.
  • the first global consensus block is synchronized from the main chain of the core consensus node when packaging the local consensus transaction.
  • the main chain read data set is cleared from the first global contract state and is used to execute the local consensus transaction.
  • the first global contract state is the read data set read when executing the global consensus transaction in the first global consensus block.
  • the local consensus node can obtain the cached local consensus transactions from the transaction pool and package the local consensus transactions into the proposal block.
  • the proposal block includes block data such as the block header and the packaged transaction list.
  • the block height of the global consensus block synchronized from the main chain can be obtained from the main chain sub-ledger database, and the block height synchronized at this time is used as the main chain binding height.
  • the local consensus node can also obtain the main chain read data set associated with the currently packaged local consensus transaction from the synchronized global consensus block.
  • the main chain read data set refers to the data that needs to be read from the main chain when executing the local consensus transaction, such as the contract status associated with the global consensus business contract.
  • the local consensus node can package the main chain binding height and the main chain read data set, as well as the local consensus transaction, into the proposal block to obtain a proposal block associated with the main chain.
  • Figure 4 is a schematic diagram of a proposal block provided in an embodiment of the present application; wherein, the proposal block 4-1 may include block header data 4-11 (such as block height, proposer, random number, timestamp and other data), a transaction list 4-12 of a local consensus transaction (such as including transaction 1, transaction 2, ....), a main chain binding height 4-13 and a main chain read data set 4-14; the main chain read data set 4-14 represents the global contract state that needs to be read from the main chain when executing the local consensus transaction in the transaction list 4-12, and the main chain read data set 4-14 includes one or more key-value pairs (for example, expressed as [key1: value1; key2: value2; ....]), "keyx: valuex” represents a key-value pair, "keyx” keyx represents the key-value data read, and "
  • the global consensus block that is most recently synchronized when the local consensus transaction is packaged can be called the first global consensus block; that is, the main chain binding height is the block height of the first global consensus block synchronized from the main chain maintained by the core consensus node when the local consensus transaction is packaged. For example, if the current block height of the global consensus block on the main chain is 100, and the block height of the global consensus block that the local consensus node has most recently synchronized from the main chain when packaging the local consensus transaction is 80, then the main chain binding height is 80, and the most recently synchronized global consensus block is the first global consensus block.
  • the global consensus block corresponding to the maximum global block height is obtained from the main chain through the core consensus node
  • the global consensus block corresponding to the maximum global block height is used as the first global consensus block
  • the maximum global block height is used as the main chain binding height.
  • the local consensus node will synchronize the latest global consensus block on the main chain from the main chain, and use the latest global consensus block on the main chain as the first global consensus block, and use the block height of the latest global consensus block on the main chain as the main chain binding height.
  • the main chain sub-ledger database is used to store the first global consensus block synchronized from the main chain and the first global contract state associated with the first global consensus block.
  • the first global contract state is the set of read data read when the global consensus business contract on the main chain is called in the core consensus network to execute the global consensus transaction in the first global consensus block.
  • the main chain read data set is the set of read data required to be read from the first global contract state data for executing local consensus transactions.
  • the local consensus node can determine the data to be used on the main chain (that is, key-value data) for the local consensus transaction when packaging the local consensus transaction, and read the data to be used from the main chain sub-ledger database (that is, read the latest value data from the main chain sub-ledger database according to the key-value data), thereby obtaining the main chain read data set and completing the data reference to the main chain.
  • the lottery rules can be declared in the global consensus business contract as a global contract state.
  • the local consensus node When the local consensus node synchronizes data from the main chain, it will also synchronize this global contract state and put it into the main chain sub-ledger database.
  • a local Consensus transaction When packaging the lottery business transaction initiated by the business party (called a local Consensus transaction), if it is determined that the global contract state corresponding to the lottery rules is read from the main chain, the lottery rules are obtained from the main chain sub-ledger database to construct the main chain read data set and package it into the local consensus block.
  • the subsequent local consensus node can read the lottery rules from the main chain read data set when executing the lottery business transaction in the local consensus block, and execute the lottery business transaction based on the lottery rules read from the main chain and the relevant local consensus business contract.
  • the lottery rules represent the data referenced from the main chain. It can be understood that according to different local consensus transactions, the global contract state referenced from the main chain in different scenarios is different, determined according to the specific blockchain scenario, which is only an example here and is not limited.
  • the main chain binding height is used to bind the local consensus block currently undergoing block consensus to the main chain for state binding (also known as contract state data binding).
  • state binding also known as contract state data binding
  • the local consensus block will determine the block height of the synchronized global consensus block when packaging the local consensus transaction, and obtain the latest main chain read data set from the data synchronized to the main chain.
  • the main chain binding height is 100
  • the global consensus block synchronized to the main chain when packaging the local consensus transaction is the global consensus block with a block height of 100
  • the global contract state data associated with the synchronized global consensus block with a block height of 100 and the previous global consensus block i.e., the global consensus block with a block height of 0-100
  • the latest read data set required to execute the local consensus transaction is cleared as the main chain read data set.
  • the local consensus network is created by the core consensus node in the core consensus network.
  • the local consensus node When creating the local consensus network, the local consensus node will create the genesis block of the local consensus subchain to start the local consensus subchain; the process includes: synchronously writing the target consensus block with the registration transaction from the main chain, the registration transaction is a business transaction that points to the core consensus node to apply for registration of the local consensus subchain, the target consensus block includes the configuration transaction corresponding to the registration transaction, the configuration transaction carries the configuration information of the genesis block on the local consensus subchain, obtains the configuration information from the target consensus block, and after the configuration information is successfully verified, creates the genesis block in the local consensus network, and starts the local consensus subchain based on the genesis block. It can be understood that when the genesis block is created and the local consensus subchain is started through the core consensus network, it means that the local consensus network is created and activated.
  • the registration transaction is initiated by the business party, and the registration transaction can carry information such as the hash data of the genesis block.
  • the core consensus node executes the registration transaction to obtain the local consensus subchain identifier, and writes the registration transaction and the local consensus subchain identifier into the main chain. For example, after writing into the main chain, the block height where the registration transaction is located is X.
  • the business party can initiate a configuration transaction, which carries the configuration information of the genesis block in the local consensus subchain.
  • the core consensus node can write the configuration transaction into the main chain.
  • the local consensus node first needs to synchronize at least the global consensus block with a block height of X from the main chain (i.e., the target consensus block), and search for the configuration information of the genesis block from the synchronized global consensus block. If the global consensus block with a block height of X is not found, it will continue to synchronize subsequent global consensus blocks until the global consensus block containing the configuration information is found.
  • the local consensus node can specify the identifier of the local consensus subchain and configure the configuration information of the genesis block through the subchain startup service, and compare the configuration information obtained from the main chain and the configuration information configured in the local consensus node (that is, the configuration information is successfully verified). When the comparison result indicates consistency (that is, the information verification is successful), a genesis block is created to start the local consensus subchain. At this time, the local consensus network is started accordingly.
  • the local verification node is the consensus node other than the local consensus node in the local consensus network.
  • the local consensus block when a local consensus block is to be block-consensused, the local consensus block must first be broadcast to the local verification nodes in the local consensus network.
  • the local verification node is a consensus node other than the local consensus node in the local consensus network.
  • the local consensus network may include multiple local consensus nodes.
  • any local consensus node packages a local consensus transaction to generate a local consensus block and performs block consensus on the local consensus block, the remaining local consensus nodes in the local consensus network can serve as local verification nodes of the current local consensus node.
  • any local verification node receives a local consensus block, it is necessary to perform block consensus on the local consensus block.
  • the remaining local consensus nodes corresponding to any local verification node are also local verification nodes of any local verification node.
  • the block consensus process performed is the same.
  • each local consensus block determines that the local consensus block has reached a block consensus
  • each local consensus node links the local consensus block to the local consensus subchain.
  • the block consensus process of the local verification node on the local consensus block can be: data audit of the main chain binding height and the main chain read data set in the local consensus block, and the block header and transaction list in the local consensus block are verified for legitimacy (for example, format verification and validity verification of the local consensus transaction in the transaction list). If the data audit is successful and the legitimacy verification is successful, the transaction execution result obtained by executing the local consensus transaction is voted on to obtain a voting consensus result, which will be sent to the remaining local consensus nodes; if the data audit is unsuccessful or the legitimacy transaction is unsuccessful, the block consensus process is terminated.
  • the process and principle of data audit of the main chain binding height and the main chain read data set by each local verification node are the same, including: obtaining the block height of the global consensus block that is latest synchronized from the main chain when the block consensus is performed from the main chain sub-ledger database, and the block height of the latest synchronized global consensus block (called the block height of the second global consensus block), and auditing the main chain binding height and the main chain read data set according to the block height of the second global consensus block.
  • local consensus nodes can synchronize global consensus blocks from the main chain, and accordingly, local verification nodes will also continuously synchronize global consensus blocks from the main chain.
  • the process of synchronizing the global consensus block can be: calling the main chain clearing synchronization component to generate a main chain clearing synchronization request, the main chain clearing synchronization request carries the block height of the first global consensus block, sending the main chain clearing synchronization request to the core consensus node, receiving the global block to be synchronized returned by the core consensus node, and at this time, the global block to be synchronized can be used as the second global consensus block.
  • the main chain clearing synchronization request is used to instruct the core consensus node to determine the global consensus block that has not been synchronized to the local consensus node from the main chain based on the global clearing synchronization rule and the block height of the first global consensus block, and select the global block to be synchronized from the global consensus block that has not been synchronized to the local consensus node.
  • the local consensus node receives the global block to be synchronized, it can determine whether the global block to be synchronized is the same as the first global consensus block, that is, to determine the block height of the global block to be synchronized and the block height of the first global consensus block.
  • the data audit of the main chain binding height and the main chain read data set according to the block height of the second global consensus block can be that the block height of the second global consensus block is used as the block height to be confirmed. If the main chain binding height is less than or equal to the block height to be confirmed, the read data set associated with the first global consensus block is searched from the main chain sub-ledger database, and the read data set is used as the read data set to be confirmed. If the read data set to be confirmed is consistent with the main chain, If the read data set is consistent, it means that the data audit is successful. That is to say, the local verification node will obtain the read data set associated with the first global consensus block from the local main chain sub-ledger database based on the main chain read data set.
  • the read data set associated with the first global consensus block includes key-value data contained in multiple key-value pairs, which are the same as the key-value data contained in multiple key-value pairs included in the main chain read data set.
  • the local verification node searches for the value data corresponding to the key-value data locally to construct the read data set associated with the first global consensus block. By comparing the main chain read data set with the locally stored read data set, the consistency of the referenced main chain data can be ensured.
  • the main chain read data set includes a key-value pair representing a lottery rule.
  • the local verification node can search for the lottery rule from the local main chain sub-ledger database.
  • the searched lottery rule is the key-value pair in the read data set associated with the first global consensus block (that is, the key-value pair in the read data set to be confirmed).
  • the lottery rules in the main chain read data set and the lottery rules in the read data set to be confirmed can be compared to determine whether the key-value pair in the main chain read data set in the local consensus block is consistent with the key-value pair synchronized locally.
  • the main chain binding height is less than or equal to the block height to be confirmed, it means that the global consensus block synchronized by the local verification node during block consensus is equal to or more than the global consensus block synchronized by the local consensus node when packaging the local consensus transaction.
  • the local verification node locally stores the global contract state synchronized by the local consensus node when packaging the local consensus transaction, so the local verification node can perform data audit through the main chain read data set.
  • the main chain binding height is greater than the block height to be confirmed, it means that the global consensus block synchronized by the local verification node during block consensus is less than the global consensus block synchronized by the local consensus node when packaging the local consensus transaction.
  • the local verification node does not locally store all the global contract states synchronized by the local consensus node when packaging the local consensus transaction, so the local verification node cannot perform consistency verification on the main chain read data set, and cannot participate in the voting consensus of the local consensus block.
  • the main chain binding height is less than or equal to the block height to be confirmed, it means that the local verification node has been synchronized to the global consensus block corresponding to the main chain binding height (that is, the first global consensus block). Therefore, the global contract state associated with the global consensus block with the synchronized block height as the main chain binding height and the previous global consensus block (that is, the global consensus block from block height 0 to the main chain binding height) can be found to obtain the set of read data to be confirmed.
  • the local verification node When the local verification node performs voting consensus, it includes: performing block consensus on the local consensus block to obtain the block consensus result, performing voting consensus based on the block consensus result, and obtaining the voting consensus result.
  • performing block consensus on the local consensus block to obtain the block consensus result can be to call the local consensus business contract to execute the local consensus transaction in the local consensus block, and use the transaction execution result obtained by executing the local consensus transaction as the block consensus result when performing block consensus on the local consensus block.
  • Voting consensus based on the block consensus result can be to compare the block consensus result between consensus nodes.
  • a voting consensus result indicating voting approval can be generated, which indicates that the block consensus result is consistent, that is, the local verification node agrees to chain the local consensus block to the local consensus subchain.
  • the voting consensus result of a local verification node will be sent to other local verification nodes and local consensus nodes, and it will also receive the voting consensus results sent by other local verification nodes and local consensus nodes.
  • the local consensus node that packages and generates the local consensus block will also execute the above-mentioned voting consensus process and send the obtained voting consensus results to the local verification node.
  • each local consensus node in the local consensus network when each local consensus node in the local consensus network performs block consensus on the local consensus block, it will execute the local consensus transaction in the local consensus block to obtain the block consensus result, and The local consensus nodes (partial consensus nodes and local verification nodes) mutually verify whether the block consensus results are consistent to generate the corresponding voting consensus results.
  • Each local consensus node can receive the voting consensus results generated by the other local consensus nodes.
  • each local consensus node when it performs block consensus, it will perform the steps of data auditing the main chain binding height and the main chain read data set, and during the data audit, it will determine whether the block height of the synchronized global consensus block is greater than or equal to the main chain binding height, and from the global consensus block corresponding to the main chain binding height and the global contract state associated with the previous global consensus block, find the read data set associated with the first global consensus block as the data set to be confirmed, and perform consistency verification on the main chain read data set based on the data set to be confirmed.
  • Figure 5 is a schematic diagram of a data audit scenario provided by an embodiment of the present application; as shown in Figure 5, for example, at this time, the local consensus node 50a packages the local consensus transaction at time point A, obtains the block height of the global consensus block synchronized at time point A (that is, the block height of the first global consensus block), for example, the height value of the block height synchronized at this time is 100, then the block height 100 is used as the main chain binding height, and the main chain read data set is searched from the global contract state associated with the global consensus blocks 0 to 100 in the main chain sub-ledger database (for example, the key-value pairs in the main chain read data set here can be expressed as: [k1:v1; k2:v2]), thereby broadcasting the obtained local consensus block to local consensus nodes 50b, 50c and 50d.
  • the key-value pairs in the main chain read data set here can be expressed as: [k1:v1; k2:v2]
  • the main chain synchronization height maintained locally at time point B can be obtained.
  • the main chain synchronization height maintained locally by the local consensus node 50b refers to the block height of the global consensus block synchronized from the main chain maintained by the local consensus node 50b at present (that is, at the audit timestamp of time point B) (that is, the block height of the second global consensus block); for example, at this time, the global consensus block synchronized from the main chain currently maintained by the local consensus node 50b is If the height value of the block height is 99, the block height with a height value of 99 can be used as the block height to be confirmed, and then when it is determined that the block height to be confirmed is less than the main chain binding height, it can be confirmed that the main chain synchronization height maintained locally lags behind the main chain synchronization height; at this time, the local consensus node 50b itself has no way to vote for the block (that is, the local consensus node 50b does not have the transaction read data set required to execute the local consensus transaction at this time), and then determines the audit failure information of the local consensus block (called the data audit result),
  • the main chain synchronization height maintained locally at time point B can be obtained.
  • the main chain synchronization height maintained locally by the local consensus node 50c refers to the block height of the global consensus block synchronized from the main chain maintained by the local consensus node 50c at present (that is, at the audit timestamp of time point B) (that is, the block height of the second global consensus block); for example, at this time, the block height synchronized from the main chain currently maintained by the local consensus node 50c is 100, then the block height with a height value of 100 can be used as the block height to be confirmed, and then it can be determined that the block height to be confirmed is equal to the main chain binding height; at this time, the local consensus node 50c can vote on the block (that is, The local consensus node 50c now has the transaction read data set required for executing the local consensus transaction in the local
  • v1 and v1′ are different or v2 and v2′ are different, it indicates that the read data set to be confirmed and the main chain read data set are inconsistent, thereby generating audit failure information for the local consensus block (that is, the data audit result), and the audit failure information is used to indicate that the data audit is unsuccessful.
  • the process of data audit of the local consensus block by the local consensus node 50d at time point B is similar to the process of data audit of the local consensus block by the local consensus node 50c at time point B, and the embodiments of the present application will not be repeated here.
  • the key-value pairs in the to-be-confirmed read data set of the local consensus node 50d can be expressed as: [k1:v1′′; k2:v2′′]), v1′′ and v2′′ represent the value data found locally by the local consensus node 50d.
  • v1 and v1′′ are the same, and v2 and v2′′ are the same, it indicates that the to-be-confirmed read data set is consistent with the main chain read data set, thereby generating audit success information, indicating that the data audit is successful; when v1 and v1′′ are different or v2 and v2′′ are different, it indicates that the to-be-confirmed read data set is inconsistent with the main chain read data set, thereby generating audit failure information, indicating that the data audit is unsuccessful.
  • the time points B corresponding to the local consensus nodes 50b to 50d may be different.
  • the local consensus node can receive the voting consensus result returned by the local verification node, and determine whether to reach a block consensus (also known as reaching a consensus) based on the received voting consensus result and the voting consensus result determined by itself (that is, determining whether the block consensus result obtained by itself is consistent with the block consensus result obtained by the local verification node). If it is determined that the number of voting consensus results indicating voting approval exceeds a certain number (such as 51% of the number of local consensus nodes in the local consensus network), it means that a block consensus has been reached. At this time, the local consensus node can write the local consensus block into the maintained local consensus subchain and into the local local consensus ledger database.
  • a block consensus also known as reaching a consensus
  • the local verification node will also receive these voting consensus results, and determine that a block consensus has been reached based on these voting consensus results, so as to put the local consensus nodes on the chain of the local consensus subchains maintained by each other and write them into their respective local consensus ledger databases.
  • the local consensus subchain and the local consensus ledger database fully store the data references of the local consensus block to the main chain.
  • the block consensus of the local consensus block can be realized in the local consensus network, and the local consensus block that reaches the block consensus can be chained to the local consensus sub-chain independent of the main chain, and the local consensus block has an association relationship with the main chain.
  • the local consensus block can not only reference the data on the main chain based on the association relationship, but also verify the consistency of the referenced data based on the association relationship, ensuring that the business transaction can be executed safely and accurately.
  • this block consensus method it is convenient to build and use the local consensus sub-chain, so that a multi-layer chain network can be constructed, which includes a core consensus network and a business network deployed with a local consensus network.
  • the multi-layer chain network realizes the hierarchical division of the blockchain network.
  • the local consensus nodes in the local consensus network can obtain the data on the main chain in the core consensus network, and can also be used for local consensus locally, so that each local consensus node of the local consensus network can process the relevant business transactions in the area where the local consensus network is located, forming a multi-level hierarchy of business transactions. For example, business transactions related to the whole country can be executed by the core consensus nodes in the core consensus network, and business transactions related to a certain region can be executed by the local consensus nodes in the local consensus network associated with the region. At the same time, the data isolation of business transaction data can be achieved through the local consensus network.
  • the business transaction data related to region A is chained to the local consensus subchain in the local consensus network associated with region A
  • the business transaction data related to region B is chained to the local consensus subchain in the local consensus network associated with region B to ensure the security of important transaction data.
  • the local consensus network can also share the business processing pressure of the main chain and ensure the stability of business processing on the main chain.
  • the multi-level stratification of business transactions can be: running the main chain in the core consensus network, the core consensus nodes in the core consensus network can be used to execute nationwide invoice business transactions, and each first-level regional invoice agency (such as national tax agencies) can create its own local consensus network and build its own local consensus sub-chain in its own local consensus network.
  • each first-level regional invoice agency such as national tax agencies
  • the business network may include multiple types of SPV nodes, such as the first type of SPV nodes and the second type of SPV nodes.
  • the first type of SPV node is used to synchronize the consensus block from the blockchain maintained by the consensus node through the consensus node with a network connection relationship, and build its own blockchain.
  • the local consensus node can synchronize the global consensus block from the main chain maintained by the core consensus node through the core consensus node with a network connection relationship; that is, the local consensus node in the local consensus network can be a first-class SPV node.
  • the local consensus node in the local consensus network is referred to as a first-level SPV local consensus node.
  • the second type of SPV node may refer to a local business node that has a network connection relationship with the first type of SPV node, for example, a local business node that has a network connection relationship with the local consensus network, and the local business node may be referred to as a business SPV node here.
  • the data associated with each can be cleared from the main chain through the first-level SPV local consensus node, and the business nodes that have a network connection relationship with each local consensus network can synchronize data from the corresponding local consensus sub-chain.
  • the business SPV node can also generate business transactions (called local consensus transactions) and send them to the first-level SPV local consensus node in the corresponding local consensus network, and the first-level SPV local consensus node will package and chain the local consensus transactions. It can be understood that business transactions that are consensused in the local consensus network will not be forwarded to the main chain, but will be processed in their respective local consensus networks.
  • the business SPV node also clears the associated data on the local consensus sub-chain through the first-level SPV local consensus node in the corresponding local consensus network.
  • a local consensus network of the next level can also be created in the business network through an SPV node.
  • each secondary regional bill institution (such as a municipal tax agency) can create its own local consensus subnetwork, and the local consensus subnetwork has a network connection relationship with the corresponding local consensus network.
  • the local consensus network associated with the secondary regional bill institution is regarded as the core consensus network for the secondary regional bill institution.
  • the principle of data interaction between the local consensus network and the local consensus subnetwork is the same as the principle of data interaction between the core consensus network and the local consensus network.
  • bill business transactions related to XX city can be executed in the local consensus subnetwork
  • bill business transactions related to XX province can be executed in the local consensus network, thereby realizing the hierarchical division of the blockchain network.
  • the local consensus subchain in the local consensus subnetwork is independent of the local consensus subchain in the local consensus network.
  • the local consensus subchain in the local consensus subnetwork can synchronize data from the local consensus subchain in the local consensus network.
  • the first type of SPV nodes included in the business network can also include local consensus nodes in the local consensus subnetwork; and the local consensus nodes in the local consensus subnetwork have a network connection relationship with the local consensus nodes in the local consensus network.
  • the local consensus nodes in the local consensus subnetwork can synchronize local consensus blocks from the correspondingly maintained local consensus subchain through the local consensus nodes in the local consensus network, and build their own blockchain.
  • the local consensus subnetwork can be referred to as The local consensus nodes in the local consensus subnetwork are called secondary SPV local consensus nodes.
  • the second type of SPV nodes may include business nodes that have a network connection relationship with the local consensus nodes in the local consensus subnetwork.
  • a main chain business transaction i.e., a global consensus transaction
  • the transaction summary information corresponding to the execution result of the global consensus transaction is uploaded to the main chain, and an information chain transaction corresponding to the transaction summary information is generated, and the main chain business transaction is sent to the core consensus node in the core consensus network through the entrance of the core consensus network, and the core consensus node consensuses and executes the main chain business transaction.
  • the business network may also include a third type of SPV node, which may act as a transit when the first type of SPV node and the consensus node with a network connection relationship perform data interaction.
  • the first type of SPV node may generate a clearing synchronization request and send it to the third type of SPV node, and the third type of SPV node forwards the clearing synchronization request to the consensus node with a network connection relationship.
  • the consensus node with a network connection relationship obtains the consensus block to be synchronized according to the clearing synchronization request
  • the consensus block to be synchronized is sent to the third type of SPV node
  • the third type of SPV node returns the consensus block to be synchronized to the first type of SPV node.
  • one or more third-category SPV nodes can be deployed between the local consensus network and the core consensus network, and the third-category SPV nodes between the core consensus network and different local consensus nodes can be different.
  • One or more third-category SPV nodes can be deployed between the local consensus network and the local consensus subnetwork, and the third-category SPV nodes between the local consensus network and different local consensus subnetworks can be different.
  • the third-category SPV nodes between the local consensus network and the core consensus network can be referred to as primary SPV nodes
  • the third-category SPV nodes between the local consensus network and the local consensus subnetwork can be referred to as secondary SPV nodes.
  • the first-level SPV local consensus node when it generates a main chain business transaction, it can send the main chain business transaction to the first-level SPV node, and the first-level SPV node forwards the main chain business transaction to the entrance of the core consensus network, and finally sends it to the core consensus node.
  • the first-level SPV node can continuously synchronize the latest global consensus block from the main chain through the core consensus node, and when receiving the main chain clearing synchronization request sent by the local consensus node, select the global block to be synchronized from the local synchronized data, and send the global block to be synchronized to the local consensus node.
  • the first-level SPV nodes corresponding to different local consensus networks are different, and a local consensus network can correspond to one or more first-level SPV nodes.
  • the next-level local consensus sub-network can be constructed based on the SPV nodes that have a network connection relationship with the local consensus network.
  • there is an SPV node between the local consensus network and the local consensus sub-network which can be called a second-level SPV node, and the working principle of the second-level SPV node is the same as that of the first-level SPV node.
  • Figures 6a and 6b are schematic diagrams of two blockchain frameworks based on multi-layer chain networks provided in the embodiments of the present application; as shown in Figure 6a, the core consensus network 600 includes core consensus nodes 60a, 60b, and 60c; the local consensus network 610 includes first-level SPV local consensus nodes 61a, 61b, and 61c; data can be directly exchanged between the local consensus network 610 and the core consensus network 600, for example, the first-level SPV local consensus node 61a can generate a main chain clearing synchronization request, and send the main chain clearing synchronization request to the core consensus node 60a through the entrance of the core consensus network, so as to synchronize the data on the main chain through the core consensus node 60a; the local consensus network 610 can communicate with the business SPV Nodes (62a, 62b, ..., 62n) interact with each other for data.
  • the core consensus network 600 includes core consensus nodes 60a, 60b, and 60c
  • the local consensus network 610 includes first
  • the business SPV node 62a can submit a business transaction to the first-level SPV local consensus node 61a, and the first-level SPV local consensus node 61a broadcasts the business transaction to the remaining first-level SPV local consensus nodes. Subsequently, the business transaction can be packaged into a block in the local consensus network 610 and uploaded to the local consensus subchain. Alternatively, the local consensus network 610 and the core consensus network 600 can interact with each other through the first-level SPV nodes.
  • the first-level SPV nodes here can include first-level SPV nodes 63a and 63b, indicating active-active service. The two first-level SPV nodes have the same functions and permissions.
  • the first-level SPV local consensus node 61a can send the generated main chain clearing synchronization request to the first-level SPV node 63a, which is sent by the first-level SPV node 63a to the core consensus node 60a through the entrance of the core consensus network.
  • the core consensus node 60a obtains the data to be synchronized from the main chain (such as the global consensus block and the global contract status) and sends it to the first-level SPV node 63a through the entrance of the core consensus network, which is returned by the first-level SPV node 63a to the first-level SPV local consensus node 61a.
  • the main chain such as the global consensus block and the global contract status
  • a local consensus subnetwork 620 can be created based on FIG. 6a .
  • the local consensus subnetwork 620 includes secondary SPV local consensus nodes 64a, 64b, and 64c.
  • the local consensus subnetwork 620 can directly interact with the local consensus network 610 for data.
  • the secondary SPV local consensus node 64a can send the generated subchain clearing synchronization request to the primary SPV local consensus node 61a through the entrance of the local consensus network to synchronize the data on the local consensus subchain through the primary SPV local consensus node 61a.
  • the local consensus subnetwork 620 can interact with the business SPV nodes 65a, 65b, ... 65n for data.
  • the business SPV node 65a can submit a business transaction to the secondary SPV local consensus node 64a, and the secondary SPV local consensus node 64a broadcasts the business transaction to the remaining secondary SPV local consensus nodes. Subsequently, the business transaction can be packaged into a block in the local consensus network 620 and chained to the local consensus subchain in the local consensus subnetwork 620. In addition, data can be exchanged between the local consensus sub-network 620 and the local consensus network 610 through the secondary SPV node.
  • the secondary SPV node here can include the secondary SPV nodes 66a and 66b, indicating that the service is active-active, and the two secondary SPV nodes have the same functions and permissions.
  • the process of performing block consensus in the local consensus network 610 can be: the first-level SPV local consensus node 61a (referred to as the local consensus node) packages the local consensus transaction, and obtains the main chain binding height and the main chain read data set when packaging the local consensus transaction, thereby storing the main chain binding height, the main chain read data set and the local consensus transaction in the proposed block, and the proposed block is used as the local consensus block to be consensused.
  • the local consensus block is broadcast to the first-level SPV local consensus nodes 61b and 61c (referred to as local verification nodes).
  • the first-level SPV local consensus nodes 61a, 61b and 61c all perform the same block consensus steps, and the executed block consensus steps are similar to the block consensus steps of the local consensus nodes and the local verification nodes, and the embodiments of the present application will not be repeated here.
  • the first-level SPV local consensus node 61a executes the local consensus transaction in the local consensus block to obtain a block consensus result; then It verifies whether the block consensus result obtained by the first-level SPV local consensus nodes 61b and 61c is consistent with the block consensus result obtained by the first-level SPV local consensus node 61a.
  • voting consensus results corresponding to the first-level SPV local consensus nodes 61a, 61b, and 61c are all voting consensus results of a vote in favor, it is determined that a block consensus is reached, and the local consensus block is chained to the local consensus subchain maintained by the first-level SPV local consensus node 61a.
  • the subchain clearing synchronization request carries the local block height synchronized to the local business node from the local consensus subchain (the local consensus subchain is maintained by the local consensus node, and the local block height is the block height of the local consensus block). Based on the local clearing synchronization rules and the local block height, determine the local consensus blocks that have not been synchronized to the local business node from the local consensus subchain, and select the local blocks to be synchronized from the local consensus blocks that have not been synchronized to the local business node, and obtain the local blocks to be synchronized.
  • the local contract status is the set of read data read by executing the local consensus transaction in the local block to be synchronized.
  • the local consensus transaction is executed by the local consensus business contract on the local chain of the local consensus network, thereby realizing data synchronization of the local consensus sub-chain.
  • the local business node can sort out the business data related to itself from the synchronized data.
  • the local business node here can refer to the business SPV node of the local consensus network (such as the business SPV node 62a in Figure 6a), and can also refer to the consensus node in the local consensus subnetwork of the next level of the local consensus network (such as the secondary SPV local consensus node 64a in Figure 6b).
  • the local block height carried by the subchain clearing synchronization request is equivalent to the block height of the first global consensus block.
  • the local contract state returned by the local consensus node to the local business node involves the data referenced from the main chain by the consensus block to be synchronized, that is, the main chain read data set in the consensus block to be synchronized.
  • the local business node is a consensus node in the local consensus subnetwork
  • the local business node can also build a blockchain in the local consensus subnetwork that is independent of the local consensus subchain in the local consensus network.
  • the local consensus block that is not synchronized to the local business node refers to the unsynchronized consensus block determined from the local consensus subchain when the local consensus node receives the subchain clearing synchronization request; for example, it can be a local consensus block whose block height on the local consensus subchain is greater than the local block height. It can be understood that at this time, it may be determined that there is no local consensus block on the local consensus subchain that is not synchronized to the local business node.
  • the local consensus node is determined from the local consensus subchain based on the local clearing synchronization rules and the local block height.
  • the process and principle of the local block to be synchronized are similar to the process and principle of the core consensus node determining the global block to be synchronized from the main chain.
  • the process of the local consensus node determining the local block to be synchronized can be: determine the synchronization result based on the local clearing synchronization rule and the local block height; when the synchronization result indicates that there is no local consensus block on the local consensus subchain that has not been synchronized to the local business node, obtain the local consensus block with the maximum local block height from the local consensus subchain, and use the local consensus block with the maximum local block height as the local block to be synchronized; when the synchronization result indicates that there is at least one local consensus block on the local consensus subchain that has not been synchronized to the local business node, use at least one local consensus block that has not been synchronized to the local business node as the local block to be synchronized.
  • the maximum local block height on the local consensus subchain is the block height carried in the subchain clearing synchronization request, that is, the local consensus block corresponding to the maximum local block height on the local consensus subchain is the latest local consensus block synchronized to the local business node.
  • the local consensus node can return the local consensus block corresponding to the maximum local block height on the local consensus subchain to the local business node.
  • a notification message indicating that no new local consensus blocks have been added can also be generated and returned to the local business node.
  • the local consensus node can use the new local consensus block as a local block to be synchronized to the local business node.
  • the local business node can obtain the local consensus block corresponding to the maximum local block height from the local consensus subchain through the local consensus node.
  • local business nodes can synchronize data on the local consensus sub-chain, but since the local consensus blocks on the local consensus sub-chain can reference data on the main chain, local business nodes can also synchronize this part of the referenced main chain data, that is, they can synchronize to the main chain data related to themselves through the local consensus nodes, thereby ensuring the security and privacy of transaction data on the main chain, and facilitating global management of the local consensus sub-chain through the main chain.
  • the local consensus node can also generate business transactions that need to be executed on the main chain, including transaction aggregation processing of the transaction execution results corresponding to the local consensus transaction based on the transaction chain rules, obtaining the aggregated transaction information, and generating the information chain transaction carrying the aggregated transaction information, calling the main chain forwarding chain component to generate the main chain chain request carrying the information chain transaction; then send the main chain chain request to the core consensus node, and the main chain chain request is used to instruct the core consensus node to write the information chain transaction to the main chain, so as to write the aggregated transaction information to the main chain.
  • the transaction aggregation processing can be a transaction aggregation processing of the transaction execution results in the local consensus block that has reached the current block consensus, and it can also be a transaction aggregation processing of the transaction execution results in the local consensus block that has reached the current block consensus and the previous local consensus block.
  • the specific rules for transaction aggregation processing are not limited here.
  • the transaction summary processing is used to instruct the transaction results (such as lottery results) obtained from the lottery business transactions executed at the specified time to be summarized to obtain transaction summary information (such as the age of the winner, the amount of the prize, and other statistical information); then an information chain transaction corresponding to the transaction summary information is generated, so that the core consensus node can write the transaction summary information into the main chain according to the information chain transaction.
  • transaction results such as lottery results
  • transaction summary information such as the age of the winner, the amount of the prize, and other statistical information
  • the embodiment of the present application proposes a consensus mechanism for local consensus blocks, through which a local consensus block associated with the main chain can be generated, and the association is based on the main chain binding height packaged into the local consensus block and the main chain read data set.
  • the data in the main chain sub-ledger database is synchronized from the main chain in the core consensus network; the main chain binding height is the block height of the first global consensus block synchronized from the main chain when packaging the local consensus transaction, and the main chain read data set is cleared from the main chain sub-ledger database.
  • the read data set allocated for executing the local consensus transaction in the local consensus block is the data referenced from the main chain when executing the local consensus transaction.
  • the local consensus node audits the main chain binding height and the main chain read data set, and performs the subsequent block consensus process after the data audit is successful.
  • block consensus By conducting block consensus on the local consensus block in the local consensus network and writing the local consensus block that reaches the block consensus into the local consensus subchain, it is possible to build a local consensus subchain independent of the main chain, which facilitates the hierarchical management of the transaction data of the business transactions of each business party.
  • each business party can build its own local consensus subchain to store the business data related to each business party in the local consensus block of each local consensus subchain (such as the transaction data involved in the execution of business transactions by business party A can be linked to the local consensus subchain A, and the transaction data involved in the execution of business transactions by business party B can be linked to the local consensus subchain B), so that the local consensus network
  • the transaction data involved in executing a transaction can be stored in an associated local consensus subchain to ensure the security, privacy and data isolation of important transaction data.
  • the data on the main chain can be directly and quickly referenced when executing a local consensus transaction in the local consensus block, avoiding the cumbersome cross-chain process between the main chain and the local consensus subchain.
  • auditing the main chain binding height and the main chain read data set can also ensure the consistency of the data referenced from the main chain when executing local consensus transactions. This is to facilitate the block consensus of the local consensus block, thereby facilitating the construction and use of the local consensus subchain.
  • FIG. 7 is a flow chart of a blockchain data processing method provided by an embodiment of the present application.
  • the method can be executed by a local consensus node and a local verification node in a local consensus network; for example, the local consensus node can be any consensus node (such as local consensus node 10a) in the local consensus network 100a shown in FIG. 1 , and the local verification node can be any consensus node (such as 10b) in the local consensus network 100a shown in FIG. 1 except the local consensus node.
  • the method includes steps S701 to S706, and each step is described below.
  • the local consensus node when the local consensus node packages the local consensus transaction cached in the local consensus node into the proposal block, it packages the main chain binding height and the main chain read data set obtained from the main chain sub-ledger database into the proposal block, and uses the proposal block containing the main chain binding height, the main chain read data set and the local consensus transaction as the local consensus block to be agreed upon.
  • step S701 may refer to the relevant description of the above embodiment.
  • the local consensus block is broadcast to the local verification nodes in the local consensus network.
  • a local verification node may refer to a consensus node other than a local consensus node in a local consensus network.
  • the local consensus node performs data audit on the main chain binding height and the main chain read data set in the local consensus block, and performs block consensus on the local consensus block when the data audit is successful to obtain a block consensus result.
  • the local consensus node when the local consensus node performs block consensus on the local consensus block, it will also perform the step of data auditing the main chain binding height and the main chain read data set. It can be understood that when the local consensus node performs block consensus on the local consensus block, it can call the local consensus business contract on the local consensus subchain corresponding to the local consensus network to perform data audit on the main chain binding height and the main chain read data set in the local consensus block to obtain the data audit result. When the data audit result indicates that the data audit is successful, the local consensus block is then subjected to block consensus. In addition, the local consensus business contract is called to execute the local consensus transaction in the local consensus block, and the transaction execution result obtained by executing the local consensus transaction is used as the block consensus result when the local consensus block is subjected to block consensus.
  • the way in which the local consensus node performs data audit to obtain the data audit result can be: calling the local consensus business contract on the local consensus sub-chain to perform the following processing: obtaining the block height to be confirmed from the main chain sub-ledger database; the block height to be confirmed is the block height of the second global consensus block synchronized from the main chain through the core consensus node, and the second global consensus block is the global consensus block on the main chain synchronized when performing block consensus.
  • the block height to be confirmed is compared with the main chain binding height in the local consensus block to obtain a first comparison result, and the data audit result is determined according to the first comparison result.
  • the process of determining the data audit result according to the first comparison result can be: when the first comparison result indicates that the height of the block to be confirmed is less than the main chain binding height, a data audit result indicating that the data audit failed is generated; when the first comparison result indicates that the height of the block to be confirmed is equal to the main chain binding height, it is determined that the first global consensus block and the second global consensus block are the same global consensus block, that is, during the packaging of the local consensus transaction to the block consensus, the local consensus node is not synchronized from the main chain to the global consensus block, and the latest synchronized global consensus block (the second global consensus block) is still the first global consensus block; thus, the local consensus business contract is called to search the main chain sub-ledger database for a read data set related to the first global consensus block, and the read data set is used as the read data set to be confirmed, the key-value pair in the read data set to be confirmed is used as the first key-value pair, and the key-value pair of the main chain read data set in the local
  • the read data set related to the first global consensus block is obtained by searching the data currently synchronized to the main chain sub-ledger database, and the key-value data of each key-value pair in the read data set related to the first global consensus block is consistent with the key-value data of each key-value pair in the main chain read data set, that is, the value data of the corresponding record can be searched from the main chain sub-ledger database according to the key-value data of each key-value pair in the main chain read data set, so as to use the key-value data of each key-value pair in the main chain read data set and the corresponding value data as the read data set related to the first global consensus block.
  • the local consensus business contract is called to execute the local consensus transaction in the local consensus block, and the transaction execution result obtained by executing the local consensus transaction is used as the block consensus result when the local consensus block is performed on the block consensus; that is, when the data audit result indicates that the first key-value pair is consistent with the second key-value pair, it means that the data audit result indicates that the data audit is successful, and the local consensus business contract can be called to read the main chain read data set in the local consensus block, and the block consensus transaction in the local consensus block is executed through the read main chain read data set, so as to use the transaction execution result obtained by executing the local consensus transaction as the block consensus result when the local consensus block is performed on the block consensus. It can be understood that when the data audit result indicates that the first key-value pair and the second key-value pair remain inconsistent, it means that the data audit result indicates that the data audit has failed, and the subsequent consensus process will not be executed.
  • the local consensus business contract can be called to search the main chain sub-ledger database for the read data set associated with the first global consensus block, and the read data set is used as the read data set to be confirmed.
  • the read data set to be confirmed and the main chain read data set are compared according to the above process to obtain the data audit result.
  • the search when searching for the read data set associated with the first global consensus block, the search is performed in the first global consensus block synchronized to the main chain sub-ledger database, and in the global contract state data associated with the first global consensus block.
  • the search method can refer to the above-mentioned related description. That is to say, when the height of the block to be confirmed is greater than or equal to the main chain binding height, the read data set associated with the first global consensus block can be searched from the main chain sub-ledger database to obtain the data audit result. As a set of read data to be confirmed, the set of read data to be confirmed is used to verify the consistency of the main chain read data set.
  • the block height of the second global consensus block can be compared with the block height of the first global consensus block.
  • the first comparison result indicates that the block height to be confirmed is greater than the main chain binding height
  • the first global consensus block and the second global consensus block are different global consensus blocks, that is, the second global consensus block is a newly synchronized consensus block
  • the second global contract state data associated with the second global consensus block is added to the main chain sub-ledger database.
  • the second global contract state data is a set of read data read when executing the global consensus transaction in the second global consensus block, and the execution is realized by calling the global consensus business contract on the main chain in the core consensus network. It should be understood that the set of data to be confirmed is obtained based on the first global contract state data associated with the first global consensus block in the main chain sub-ledger database.
  • the block consensus result it is necessary to vote on the block consensus result, that is, to determine whether the block consensus result on the local verification node is consistent with the block consensus result on the local consensus node. For example, when a certain number of block consensus results are the same, it indicates consistency, and a voting consensus result indicating a vote in favor can be generated; when a certain number of block consensus results are not the same, it indicates inconsistency, and a voting consensus result indicating a vote against can be generated.
  • the local consensus node can send the voting consensus node to the local verification node.
  • the local verification node performs data audit on the main chain binding height and the main chain read data set in the local consensus block, and when the data audit is successful, performs voting consensus on the transaction execution result obtained by executing the local consensus transaction to obtain the voting consensus result.
  • the process and principle of data auditing by local verification nodes on the main chain binding height and main chain read data set in the local consensus block are the same as the process and principle of data auditing by local consensus nodes. That is, it is determined whether the block height of the global consensus block synchronized at the time of block consensus is greater than or equal to the main chain binding height. If it is greater than or equal to the main chain binding height, the to-be-confirmed read data set is searched from the main chain sub-ledger database, and the to-be-confirmed read data set is checked to see if it is consistent with the main chain read data set. If they are consistent, it means that the data audit is successful. Among them, when the data audit is successful, it means that the voting consensus authority is obtained. If the data audit is successful, the voting consensus will not be carried out, and no voting consensus result will be generated.
  • the process in which the local verification node executes the local consensus transaction to obtain the transaction execution result is the process in which the local verification node performs block consensus on the local consensus block to obtain the block consensus result. Therefore, the voting consensus on the transaction execution result can be to determine whether the transaction execution results on other local consensus nodes are consistent with the transaction execution results on the local verification node. If they are consistent, a voting consensus result indicating a vote in favor is generated. In addition, after the local verification node obtains the voting consensus result, it will send the voting consensus result to other local consensus nodes, and the local verification node will also receive the voting consensus node sent by other local consensus nodes.
  • the local consensus network includes local consensus nodes 70a, 70b and 70c.
  • the local consensus node 70a verifies whether the transaction execution results on the local consensus nodes 70b and 70c are consistent with its own transaction execution results and generates a corresponding voting consensus result, and sends the voting consensus result to the local consensus nodes 70b and 70c.
  • the local consensus node 70b verifies whether the transaction execution results on the local consensus nodes 70a and 70c are consistent with its own transaction execution results and generates a corresponding voting consensus result, and sends the voting consensus result to the local consensus nodes 70a and 70c.
  • the local consensus node 70c After obtaining the transaction execution result, the local consensus node 70c verifies whether the transaction execution results on the local consensus nodes 70a and 70b are consistent with its own transaction execution results and generates a corresponding voting consensus result, and sends the voting consensus result to the local consensus nodes 70a and 70c. Whether it is consistent with its own transaction execution result and generate a corresponding voting consensus result, and send the voting consensus result to the local consensus nodes 70a and 70b.
  • the local verification node returns the voting consensus result to the local consensus node.
  • the local consensus block is chained to the local consensus sub-chain corresponding to the local consensus network, and the local consensus block is written into the local consensus ledger database independent of the main chain sub-ledger database.
  • the local consensus node can determine the corresponding voting consensus result based on the block consensus result, and determine whether the block consensus is reached based on the voting consensus result obtained by itself and the voting consensus result received. If it is determined that the block consensus is reached, the local consensus block will be chained to the local consensus sub-chain corresponding to the local consensus block, and the local consensus block will be written into the local consensus ledger database of the independent main chain sub-ledger database. Correspondingly, the local verification node will also determine that the block consensus is reached, and the local consensus block will be chained to the corresponding maintained local consensus sub-chain, and the local consensus block will be written into the local local consensus ledger database.
  • the interaction process includes S1 to S23 , and each step is described below.
  • Local consensus node 70a broadcasts the local consensus block to local consensus node 70b.
  • Local consensus node 70a broadcasts the local consensus block to local consensus node 70c.
  • the local consensus node 70a performs data audit on the main chain binding height and the main chain read data set in the local consensus node, and executes the local consensus transaction in the local consensus block after the data audit is successful, and obtains the transaction execution result a.
  • the local consensus node 70b performs data audit on the main chain binding height and the main chain read data set in the local consensus node, and executes the local consensus transaction in the local consensus block after the data audit is successful, and obtains the transaction execution result b.
  • the local consensus node 70c performs data audit on the main chain binding height and the main chain read data set in the local consensus node, and executes the local consensus transaction in the local consensus block after the data audit is successful, and obtains the transaction execution result c.
  • Local consensus node 70a broadcasts the transaction execution result a to local consensus node 70b.
  • Local consensus node 70a broadcasts the transaction execution result a to local consensus node 70c.
  • Local consensus node 70b broadcasts the transaction execution result b to local consensus node 70a.
  • Local consensus node 70b broadcasts the transaction execution result b to local consensus node 70c.
  • Local consensus node 70c broadcasts the transaction execution result c to local consensus node 70a.
  • Local consensus node 70c broadcasts the transaction execution result c to local consensus node 70b.
  • the local consensus node 70a performs voting consensus on the transaction execution result a according to the transaction execution result b and the transaction execution result c, and generates a voting consensus result a.
  • voting consensus result a indicates whether the transaction execution results b and c are consistent with the transaction execution result a.
  • the local consensus node 70b performs voting consensus on the transaction execution result b according to the transaction execution result a and the transaction execution result c, and generates a voting consensus result b.
  • voting consensus result b indicates whether the transaction execution result a and the transaction execution result c are consistent with the transaction execution result b.
  • the local consensus node 70c determines the transaction execution result c based on the transaction execution result a and the transaction execution result b. Conduct voting consensus and generate voting consensus result c.
  • voting consensus result c indicates whether the transaction execution result a and the transaction execution result b are consistent with the transaction execution result c.
  • the local consensus node 70a sends the voting consensus result a to the local consensus node 70b.
  • the local consensus node 70a sends the voting consensus result a to the local consensus node 70c.
  • Local consensus node 70b sends the voting consensus result b to local consensus node 70a.
  • Local consensus node 70b sends the voting consensus result b to local consensus node 70c.
  • Local consensus node 70c sends the voting consensus result c to local consensus node 70a.
  • Local consensus node 70c sends the voting consensus result c to local consensus node 70b.
  • the local consensus node 70a determines that a block consensus has been reached based on the voting consensus results a-c, the local consensus block will be uploaded to the maintained local consensus sub-chain and written into the local main chain sub-ledger database.
  • the local consensus node 70b determines that a block consensus has been reached based on the voting consensus results a-c, the local consensus block is uploaded to the maintained local consensus sub-chain and written into the local main chain sub-ledger database.
  • the local consensus node 70c determines that a block consensus has been reached based on the voting consensus results a-c, the local consensus block is uploaded to the maintained local consensus sub-chain and written into the local main chain sub-ledger database.
  • FIG. 9 is a flowchart of a blockchain data processing method provided by an embodiment of the present application.
  • the method can be executed by a core consensus node in a core consensus network; for example, the core consensus node can be any consensus node in the core consensus network 200a shown in FIG. 1 .
  • the method can include steps S901 to S904, and each step is described below.
  • the main chain clearing synchronization request is used to request the core consensus node to obtain the data to be synchronized to the local consensus node from the main chain, and return the data to be synchronized to the local consensus node to the local consensus node.
  • the main chain clearing synchronization request can carry the block height of the first global consensus block.
  • the first global consensus block can be the global consensus block synchronized from the main chain by the local consensus node when packaging the local consensus transaction; for example, when packaging the local consensus transaction, the local consensus node can obtain the block height of the latest synchronized global consensus block from the main chain sub-ledger database, and use the latest synchronized global consensus block as the first global consensus block, and write the block height of the latest synchronized global consensus block into the main chain clearing synchronization request.
  • S902 based on the global clearing synchronization rule and the block height of the first global consensus block, determine the global consensus blocks that have not been synchronized to the local consensus nodes from the main chain, and select the global block to be synchronized from the global consensus blocks that have not been synchronized to the local consensus nodes.
  • the core consensus node determines the global consensus block that has not been synchronized to the local consensus node, it can use the global consensus block on the main chain with a block height greater than the block height of the first global consensus block as the global consensus block that has not been synchronized to the local consensus node.
  • the process of the core consensus node determining the global block to be synchronized may be: if it is determined that there is no global consensus block on the main chain that has not been synchronized to the local consensus node, then the global consensus block corresponding to the maximum global block height is obtained from the main chain, and the global consensus block corresponding to the maximum global block height is used as the global block to be synchronized; if it is determined that there is at least one global consensus block on the main chain that has not been synchronized to the local consensus node, then at least one global consensus block that has not been synchronized to the local consensus node is used as the global block to be synchronized.
  • the maximum global block height is the block height carried in the main chain clearing synchronization request, that is, the local consensus block corresponding to the maximum global block height on the main chain is the first global consensus block that has been synchronized to the local consensus node.
  • the core consensus node can return the global consensus block corresponding to the maximum global block height on the main chain to the local consensus node, that is, return the first global consensus block on the main chain to the local consensus node; it can also generate a notification message indicating that no new global consensus block has been added, and return the notification message to the local consensus node.
  • the local consensus node when it is determined that there is a global consensus block that has not been synchronized to the local consensus node, it means that there is a new global consensus block on the main chain at this time, and the core consensus node will synchronize the new global consensus block to the local consensus node as a global block to be synchronized.
  • the local consensus node can obtain the global consensus block corresponding to the maximum global block height from the main chain through the core consensus node, that is, the local consensus node synchronizes the latest global consensus block from the main chain.
  • the block height synchronized to the consensus node used for voting consensus is greater than or equal to the block height of the first global consensus block, there is a situation where the consensus node has not been synchronized to the latest global consensus block in time, so that there is a consensus node that cannot perform voting consensus. Therefore, when the core consensus node synchronizes the global consensus block on the main chain to the local consensus node, it can reduce the block height of the global consensus block synchronized from the main chain by each local consensus node through the buffer block height. For example, the block height of the global consensus block on the main chain is 100, and the buffer block height is 20. At this time, the block height of the global consensus block that the local consensus node can synchronize from the main chain is 80.
  • the process of selecting the global block to be synchronized can be: obtaining the buffer block height, and taking the sum of the block height of the first global consensus block and the buffer block height as the target block height, determining the global synchronization height based on the block height of the global consensus block that has not been synchronized to the local consensus node and the target block height, obtaining the global consensus block corresponding to the global synchronization height from the global consensus block that has not been synchronized to the local consensus node, and taking the global consensus block corresponding to the global synchronization height as the global block to be synchronized.
  • the process of determining the global synchronization height can be: if the block height of the global consensus block that has not been synchronized to the local consensus node is equal to the target block height, the block height of the first global consensus block is used as the global synchronization height; if the block height of the global consensus block that has not been synchronized to the local consensus node is greater than the target block height, the block height between the block height of the first global consensus block and the block height to be synchronized is obtained, and the block height between the block height of the first global consensus block and the block height to be synchronized is used as the global synchronization height; the block height to be synchronized refers to the sum of the height of the newly added block and the block height of the first global consensus block, and the newly added block height refers to the height difference between the maximum global block height of the global consensus block on the main chain and the target block height.
  • the global block to be synchronized can be determined according to the number of new global consensus blocks added during the period from the last synchronization of data to this synchronization of data.
  • L global consensus blocks were added during the period from the last synchronization of data to this synchronization of data, and L global consensus blocks can be synchronized to the local consensus nodes in sequence, where L is a positive integer.
  • the target block height is 100. If the block height of the global consensus block on the main chain is 103 at this time, it means that 3 new global consensus blocks have been added to the main chain during this period, so the new block height is 3; at this time, starting from the next global consensus block of the first global consensus block, 3 global consensus blocks are synchronized to the local consensus nodes in sequence, that is, the global synchronization height is 103. They are 81, 82 and 83.
  • the block height of the global consensus block that has not been synchronized to the local consensus node is equal to the target block height, it means that there is no new global consensus block on the main chain during the period from the last synchronization of data to this synchronization of data.
  • the block height of the main chain has not increased, and the difference between the block height of the main chain and the block height of the first global consensus block is equal to the buffer block height; therefore, the first global consensus block can be obtained from the main chain and synchronized to the local consensus node, or a notification message indicating that no new global consensus block has been added is generated and returned to the local consensus node.
  • the main chain data synchronization on the local consensus node can be completed through the above process. It can be understood that the main chain data synchronization process of each local consensus node in the local consensus network is the same.
  • the global contract state is the set of read data read when executing the global consensus transaction in the global block to be synchronized.
  • the global consensus transaction is executed by the global consensus business contract on the main chain in the core consensus network.
  • the global block to be synchronized and the global contract state associated with the global block to be synchronized are returned to the local consensus node, if the local consensus node is in the process of packaging local consensus transactions and block consensus, the global block to be synchronized can be the second global consensus block synchronized to the local consensus node.
  • the local consensus node can store the global block to be synchronized and the global contract state in the main chain sub-ledger database in the local consensus node.
  • the embodiment of the present application also provides a blockchain data processing method, which is executed by a core consensus node in a core consensus network, the core consensus network is deployed in a multi-layer chain network, and a business network independent of the core consensus network in the multi-layer chain network is deployed with a local consensus network, the local consensus network includes a local consensus node, and the method includes: obtaining a main chain synchronization request sent by the local consensus node, the main chain synchronization request carries the block height of a third global consensus block; the third global consensus block is a global consensus block synchronized from the main chain by the local consensus node before synchronizing to the first global consensus block; from the main chain, a global consensus block with a block height greater than the block height of the third global consensus block is synchronized to the local consensus node; block, determined as the first global consensus block that has not been synchronized to the local consensus node; the first global contract state of the first global consensus block is obtained from the main chain; the first global contract state is a set of read data
  • FIG 10 is a schematic diagram of a hierarchical structure of a blockchain network.
  • the hierarchical structure shown in Figure 10 is applied to a blockchain electronic bill system, and the blockchain network corresponding to the blockchain electronic bill system includes a business network 1000a deployed in a public network and a consensus network 2000a deployed in a private cloud.
  • business nodes 110a, 110b, 110c, 110d, 110e, 110f, 110g, ..., 110n are exemplarily shown.
  • the number of business nodes deployed in the business network 1000a is not limited here. It should be understood that the business nodes in the business network 1000a do not need to participate in bookkeeping.
  • each business node running in the business network 1000a can access one or more consensus networks through network communication, and each consensus network can also exchange data through network communication.
  • consensus network 2000a shown in FIG. 10
  • multiple consensus nodes are deployed, exemplarily shown as Except for consensus node 211a, consensus node 211b, consensus node 211c and consensus node 211d, the number of consensus nodes deployed in consensus network 2000a is not limited.
  • blockchain 211e is jointly maintained for multiple consensus nodes running in the consensus network 2000a.
  • the embodiment of the present application may collectively refer to the business nodes and consensus nodes in the blockchain electronic bill system corresponding to FIG. 10 as blockchain nodes (referred to as nodes), and may refer to the consensus network 2000a participating in the blockchain electronic bill system corresponding to FIG. 10 as a core consensus network, and may refer to each node in the core consensus network of FIG. 10 as a core consensus node. It is understandable that in the blockchain electronic bill system corresponding to FIG. 10, the business network and the consensus network may interact through a routing boundary.
  • the core consensus node is used to reach a consensus in the core consensus network where the corresponding blockchain is located, that is, the core consensus node is a consensus node in the core consensus network.
  • the process of writing the transaction data in the core consensus network in FIG10 into the corresponding blockchain account book can be: the client sends the transaction data to a certain business node, and then the transaction data is passed between the business nodes in the business network in the blockchain network in a relay manner until the consensus node in the core consensus network in the blockchain network (e.g., the consensus node 211b in the consensus network 2000a) receives the transaction data; at this time, the consensus node (e.g., the consensus node 211b in the consensus network 2000a) packs the transaction data into a block to reach a consensus among other consensus nodes; and when consensus is reached, the block is written into the distributed database of the core consensus network (e.g., the consensus network 2000a) where it is located.
  • the consensus node e.g., the consensus network 2000a
  • a smart contract can be deployed on the blockchain of the core consensus network.
  • the smart contract is a code executed by each blockchain node (i.e., each consensus node) in the blockchain electronic invoice system. Any logic can be executed and a result can be obtained through the smart contract.
  • the smart contract deployed on the blockchain e.g., blockchain 211e
  • the corresponding core consensus network e.g., consensus network 2000a
  • the business node in the business network can send the transaction business request to the consensus node in the corresponding core consensus network (for example, consensus node 211a) to authenticate the identity of the sent transaction business request through the chain entry of the corresponding core consensus network, and when the identity authentication is successful, authorize the transaction business request to be sent to other consensus nodes in the corresponding core consensus network (for example, consensus node 211b) to call the smart contracts running in these consensus nodes (for example, consensus node 211a and consensus node 211b shown in Figure 10) to execute the transaction business requested by the user.
  • consensus node 211a consensus node 211a
  • consensus node 211b the consensus node 211b
  • an embodiment of the present application also provides a multi-layer blockchain, which includes a main chain and local consensus sub-chains under the main chain.
  • the main chain can be maintained by the core consensus nodes in the consensus network in the hierarchical structure of the blockchain network in Figure 10
  • the local consensus nodes used to maintain the local consensus sub-chains under the main chain can be located in the business network.
  • the local consensus sub-chains can also be called local sub-chains, local chains, etc.
  • the core consensus network corresponding to the main chain is used to process bill business nationwide; and, under the main chain, a local consensus subchain can be deployed for each provincial region, and the local consensus network corresponding to each local consensus subchain is used to interact with the business nodes in the provincial region for data processing in the provincial region; the local consensus network used for processing bill business in the provincial region can also be called a provincial local consensus network, and the local consensus subchain maintained by the provincial local consensus network can be called a provincial local consensus subchain.
  • FIG 11 is a schematic diagram of the structure of a multi-layer blockchain network provided by an embodiment of the present application.
  • a local consensus network 21 and a core consensus network 22 may be included in a multi-layer blockchain network.
  • the local consensus network 21 (for example, a provincial local consensus network) can be used to maintain a local consensus subchain and process business transactions (for example, electronic bill business transactions) submitted by business nodes in a first-level (for example, provincial) area.
  • the consensus nodes in the local consensus network 21 can be lightweight nodes (SPV nodes), also known as first-level SPV local consensus nodes (also known as local consensus nodes), such as the first-level SPV local consensus nodes 21a, 21b, 21c, 21d and 21e shown in Figure 11.
  • SPV nodes lightweight nodes
  • first-level SPV local consensus nodes also known as local consensus nodes
  • local consensus nodes such as the first-level SPV local consensus nodes 21a, 21b, 21c, 21d and 21e shown in Figure 11.
  • multiple local consensus networks can also be included in the multi-layer blockchain network for processing business transactions in different first-level regions.
  • the local consensus network 21 is described as an example, and the local consensus networks corresponding to other first-level regions can refer to the relevant description of the local consensus network 21.
  • the core consensus network 22 is used to maintain the main chain in the multi-layer blockchain and process the overall (for example, nationwide) electronic bill business.
  • the blockchain nodes in the core consensus network can be called core consensus nodes, such as the core consensus nodes 22a, 22b and 22c shown in Figure 11.
  • the local consensus network 21 can exchange data with the core consensus network 22, so that a safe and efficient business flow system can be constructed under the premise of mutual cooperation between the local consensus network and the core consensus network.
  • the electronic bill system based on the multi-layer blockchain network is conducive to hierarchical business processing, which can ensure that each region runs the business at the regional level relatively independently and reduce the business traffic on the main chain.
  • it can also reduce the business carried by the core consensus network, and realize global management while improving the execution efficiency of global tasks.
  • a multi-layer blockchain network data can be exchanged between the local consensus network 21 and the core consensus network 22 through the primary main chain SPV node.
  • multiple primary main chain SPV nodes (primary main chain SPV nodes 23a and 23b as shown in FIG11) can be included, and the roles, data and permissions of each primary main chain SPV node are exactly the same.
  • the primary main chain SPV node can synchronize the account data on the main chain maintained by the core consensus network to the local consensus node in the local consensus network, so that the local consensus node can be based on the account of the main chain. This data is used for business processing.
  • the first-level main chain SPV node can also receive the main chain business transactions submitted by each business object through the client; for example, when the business object archives the local consensus sub-chain, it can submit an archiving configuration transaction for indicating the archiving of the local consensus data on the local consensus sub-chain, and then the first-level main chain SPV node can forward the received archiving configuration transaction to the core consensus network entry 25, so that the core consensus network entry 25 forwards the received archiving configuration transaction to the core consensus node used to process the business transaction, such as the core consensus nodes 22a, 22b and 22c in Figure 11.
  • the first-level main chain SPV node can also receive business transactions sent by the local consensus node, and forward the business transactions sent by the local consensus node to the core consensus network portal 25; for example, in the execution process of the archiving business, the first-level main chain SPV node can receive a summary sending transaction (referred to as a first summary sending transaction or a second summary sending transaction) determined by the local consensus node (such as the first-level SPV local consensus node 21a shown in 11) based on the summary information of the local consensus data to be archived, and forward the summary sending transaction to the core consensus network portal 25, so that the core consensus network portal 25 can forward the received summary sending transaction to the core consensus node.
  • a summary sending transaction referred to as a first summary sending transaction or a second summary sending transaction
  • the multi-layer blockchain network may also include business SPV nodes, such as business SPV nodes 24a, 24c and 24b in FIG11.
  • the business SPV node may be a business node in the area corresponding to the local consensus network 21, and may interact with the local consensus network 21 for regional business processing.
  • a first-level SPV local consensus node in the local consensus network may receive business transactions (also referred to as local business transactions) for the local consensus subchain sent by a business SPV node (a business SPV node 24a as shown in FIG11), and then the first-level SPV local consensus node (a first-level SPV local consensus node 21a as shown in FIG11) verifies the legitimacy of the received local business transactions, and packages the verified local business transactions for consensus, so as to link the local business transactions to the first-level local consensus subchain.
  • business transactions also referred to as local business transactions
  • the first-level SPV local consensus node verifies the legitimacy of the received local business transactions, and packages the verified local business transactions for consensus, so as to link the local business transactions to the first-level local consensus subchain.
  • the business transactions submitted to the local consensus network 21 will not be forwarded to the core consensus network, but the business processing will be completed in the local consensus network.
  • the summary information in the local consensus network can also be uploaded to the core consensus network.
  • the local consensus network 21 can perform a lottery business based on invoices.
  • the first-level SPV local consensus node in the local consensus network 21 (the first-level SPV local consensus node 21a shown in Figure 11) will not forward each lottery business transaction to the core consensus network, but after completing a cycle of lottery business, it can summarize the results of the lottery within this cycle, such as summarizing the number of times each prize is drawn within this cycle, and then upload the summary information to the core consensus network 22.
  • the first-level local consensus network 21 can synchronize the ledger data on the main chain and store the ledger data associated with itself obtained by clearing, so that the local consensus network can refer to the data synchronized from the main chain when processing local business transactions, such as the read value set (Read Key-Value Set) of the contract status of the contract used when the main chain executes the transaction in the block.
  • the business object is based on the electronic ticket issued on the main chain for lottery, and the lottery business transaction is carried out in the local consensus network.
  • the local consensus node can determine the relevant data required for the lottery business transaction from the data synchronized from the main chain stored by itself, such as the list of companies that can participate in the lottery, and the proportion of participating in the lottery, and then process the lottery business transaction based on the data related to the lottery business transaction synchronized from the main chain.
  • the local consensus node 300a may include components shown in areas 31 and 32, the components in area 31 are used to receive local business transactions, package local business transactions into blocks, and perform block consensus and chain on the packaged blocks to obtain local consensus blocks on the local consensus subchain; the components in area 32 are used to synchronize the data on the main chain, and clear the main chain data related to itself from the synchronized main chain data (for example, from the contract status on the referenced main chain when executing local business transactions), and can also generate business transactions to be executed by the core consensus network, and send the business transactions to be executed by the core consensus network to the core consensus network.
  • the local consensus node 300a when it generates a business transaction to be uploaded to the main chain, it can trigger the main chain consensus RPC component 325 to call the main chain forwarding on-chain component 326 to forward the business transaction to be uploaded to the main chain to the core consensus network 33, and then the core consensus node in the core consensus network 33 can write the received business transaction to the main chain; for example, the main chain consensus RPC component 325 can perform transaction verification on the summary sending transaction to be uploaded to the main chain, and call the main chain forwarding on-chain component 326 through the main chain consensus RPC component 325 to forward the summary sending transaction with successful transaction verification to the core consensus network 33.
  • the local consensus node 300a can also send the business transaction to be sent to the core consensus network to the first-level main chain SPV node through the main chain forwarding on-chain component 326, and then the first-level main chain SPV node forwards the business transaction to the core consensus network entrance, and then the core consensus network entrance forwards the business transaction to the core consensus node for processing the business transaction.
  • the local consensus node 300a when it receives a local business transaction (for example, a local consensus transaction sent by a business object through a business node), it can call the local subchain consensus RPC component 311 to verify the local consensus transaction and put it into the transaction pool, and then call the local subchain consensus component 312 through the local subchain consensus RPC component 311 to obtain the cached local business transaction from the transaction pool, and the local subchain consensus component 312 will package the obtained local business transaction into blocks to obtain a block proposal (Proposal, called a proposed block).
  • a local business transaction for example, a local consensus transaction sent by a business object through a business node
  • the main chain binding height and the main chain reading data set can be obtained from the main chain sub-ledger database, and the local sub-chain consensus component 312 will obtain the main chain binding height and the main chain reading data set and package them into the block proposal, so that the block proposal can be bound to the main chain state through the main chain binding height, and the main chain data can be referenced through the main chain reading data set; since the block proposal at this time is a local consensus block to be agreed upon, the local sub-chain consensus component 312 is in the local consensus area to be agreed upon.
  • the local consensus block to be consensus can be broadcasted to the local verification nodes in the local consensus network to vote on the local consensus block to be consensus. If the vote reaches a consensus, the local consensus block that reaches a consensus can be used as the local consensus block on the local consensus subchain. It can be understood that the local consensus data on the local consensus subchain (such as the ledger data of the local consensus block and the contract status of the contract on the local subchain) can be stored in the local consensus ledger database 314 in the local consensus node 300a.
  • the data audit can also be performed on the main chain binding height and the main chain read data set in the local consensus block.
  • the data audit process is similar to the data audit process described in Figure 2, and the embodiment of the present application will not be repeated here.
  • the main chain binding height is lower than the latest main chain block height by a certain threshold, such as at least 20 block heights lower.
  • the local consensus subchain 300a can call the corresponding business transaction contract to perform business processing through the local chain transaction contract execution component 313. For example, when the local consensus node detects an archiving task event, it can call the contract for archiving task processing through the local chain transaction contract execution component 313 to archive data.
  • the local consensus node 300a may also include a task trigger 34, which may be triggered when it is detected that the main chain clearing synchronization component 327 has cleared a task event, and then the task trigger may determine the type of the task event, and schedule the task event based on the determined type to execute the corresponding task.
  • the main chain clearing synchronization component 327 may clear a task event that matches the local consensus subchain maintained by the local consensus node, and then the task trigger may detect the type corresponding to the cleared task event, and when the task trigger detects that the task event is an archived task event, the local chain transaction contract execution component 313 is triggered to call the target archive business contract for processing the archived task event on the local consensus subchain to process the archived task event.
  • the task trigger 34 may also forward and schedule information during task processing.
  • the local consensus node 300a may send the local consensus data to be archived to the remote backup device 35 (e.g., server) through the task trigger 34; as another example, the local consensus node 300a may trigger the main chain forwarding component 326 to upload the transaction to be sent to the core consensus network 33 through the task trigger 34.
  • an embodiment of the present application proposes a multi-layer blockchain data processing solution, which can be executed by a local consensus node (such as 300a in Figure 12) including a main chain clearing synchronization component; when the local consensus node clears the archiving task event from the first block synchronized from the main chain through the main chain clearing synchronization component, the summary corresponding to the local consensus data to be archived (such as the block data summary) is sent to the core consensus node corresponding to the main chain, and when the summary confirmation event is cleared from the second block synchronized from the main chain through the main chain clearing synchronization component, the local consensus data to be archived (such as the account book data to be backed up) is sent to the remote backup device for backup; then, when the local consensus node receives the remote backup signature (called the first backup signature) returned by the remote backup device, the remote backup signature is sent to the core consensus node, so that the core consensus node determines that the local consensus data to be archived has been backed up to the remote backup device when the
  • the embodiment of the present application can control the local consensus node to archive its local local consensus data (for example, the ledger data of the archived block stored locally by the local consensus node itself) according to the currently acquired archiving task command through the mutual cooperation between multiple layers of blockchains, so as to realize the controllability of data archiving of the local consensus data on the local consensus subchain.
  • the local consensus node since the local consensus node backs up its local ledger data to the remote backup device, the local consensus node can also archive its local consensus data to the remote backup device. Before the backup, the summary of the archived block stored locally is linked to the main chain through the core consensus node.
  • the original text of the transaction executed locally by the local consensus node can be ensured to be non-synchronous, so that when archiving the local consensus data on the local consensus subchain, the privacy and security of the transaction executed on the local consensus node can be ensured.
  • the core consensus node can also compare the summary with the first backup signature, and then ensure the data security of the ledger backup information backed up on the remote backup device during the archiving of the local consensus data on the local consensus subchain.
  • FIG. 13 is a flow chart of a multi-layer blockchain data processing process provided by an embodiment of the present application.
  • the process of archiving the ledger data on the local consensus subchain is introduced as an example.
  • the core consensus node receives the archiving configuration transaction determined by the archiving task command triggered by the business object (step S1301); then, the core consensus node synchronizes the first block containing the archiving configuration transaction to the local consensus node (step S1302); the first block belongs to the main chain consensus block on the main chain; the local consensus node can clear the archiving task event that matches the chain identifier of the local consensus subchain from the first block through the main chain clearing synchronization component (the main chain clearing synchronization component 327 shown in Figure 12); when the archiving task command indicated by the archiving task event is a ledger archiving command, the local consensus node will be based on the ledger archiving command to be archived on the local consensus subchain.
  • the local consensus block is used as an archive block (step S1303); then the local consensus node can determine the block data summary corresponding to the archive block.
  • the local consensus node can trigger the local chain transaction contract execution component (the local chain transaction contract execution component 313 as shown in Figure 12) through a task trigger (the task trigger 34 as shown in Figure 12) to determine the block data summary; then, the local consensus node sends the block data summary of the archive block to the core consensus node (step S1304), and the local consensus node can trigger the main chain forwarding chain component (the main chain forwarding chain component 326 as shown in Figure 12) through the task trigger to send the block data summary to the core consensus node.
  • the local consensus node can trigger the local chain transaction contract execution component (the local chain transaction contract execution component 313 as shown in Figure 12) through a task trigger (the task trigger 34 as shown in Figure 12) to determine the block data summary; then, the local consensus node sends the block data summary of the archive block to the core consensus node (step S1304), and the local
  • the core consensus node After receiving the block data summary, the core consensus node writes the second block into the main chain when packaging the first summary confirmation event corresponding to the block data summary into the second block (step S1305); then the core consensus node synchronizes the second block including the first summary confirmation event to the local consensus node (step S1306).
  • the local consensus node determines the account data to be backed up based on the transaction original text of all transactions in the archived block (step S1307); then the local consensus node sends the account data to be backed up to the remote backup device associated with the multi-layer blockchain (step S1308); the remote backup device performs backup processing on the account data to be backed up, and uses the account data to be backed up after the backup processing as the account backup information (step S1309); then based on the account backup information, the first backup signature is returned to the local consensus node (step S1310); and, after receiving the first backup signature, the local consensus node sends the first backup signature to the core consensus node (step S1311); after the core consensus node performs signature verification on the first backup signature, the account backup information is compared with the block data summary (step S1312), and when the comparison is successful
  • the core consensus node when the core consensus node determines that the ledger data to be backed up has been successfully backed up to the remote backup device, it can also generate backup success information, and then return the backup success information to the local consensus node, so that when the local consensus node receives the backup success information, it can clear the successfully backed up ledger data to be backed up, thereby reducing the storage pressure on the local consensus node.
  • the embodiment of the present application proposes a multi-layer blockchain data processing method.
  • Figure 14 is a diagram of the embodiment of the present application.
  • the embodiment provides a flow chart of a multi-layer blockchain data processing method. The method is executed by a local consensus node including a main chain clearing and synchronization component.
  • the multi-layer blockchain data processing method may include steps S401 to S404, and each step is described below.
  • the first block When synchronizing from the main chain to the first block, clear the archiving task events of the local consensus subchain from the first block; the first block includes an archiving configuration transaction associated with the archiving task event; the archiving configuration transaction is determined by the archiving task command triggered by the business object; the archiving task command is used to archive the local consensus data on the local consensus subchain.
  • the core consensus node associated with the main chain can receive the archive configuration transaction submitted by the business object; after verifying the legitimacy of the archive configuration transaction, the core consensus node packages the archive configuration transaction into the first block, and then the core consensus node can synchronize the first block to the local consensus node.
  • the business object is an object that includes the authority to trigger the archiving task command (for example, a personal or corporate account).
  • the business object can be a management account of an electronic ticket system based on a double-layer chain network; furthermore, the business object can trigger the archiving task command based on the corresponding business device to archive the local consensus data on the local consensus sub-chain, and the business object can determine the archiving configuration transaction based on the archiving task command, and submit the archiving task configuration transaction to the core consensus node associated with the main chain.
  • a business object when a business object triggers an archiving task command, it can specify the chain identifier of the local consensus subchain to be archived, that is, the archiving command parameter of the archiving task command can include the chain identifier of the local consensus subchain to be archived; and then the local consensus node can obtain the chain identifier of the local consensus subchain to be archived from the transaction parameters of the archiving configuration transaction determined by the archiving task command, so that the local consensus node can clear the archiving task event from the first block to the archiving configuration transaction based on the obtained chain identifier.
  • business objects can archive local consensus data on the local consensus subchain whose generation time is a certain time threshold from the current time, which is also called archiving cold data.
  • the account book data corresponding to the local consensus block generated 10 days ago can be archived.
  • the local consensus node can clear the main chain consensus block (called the first block) synchronized from the main chain to the local consensus node through the main chain clearing synchronization component to obtain the ledger data and contract data (also called contract status) associated with the local consensus sub-chain maintained by the local consensus node.
  • the ledger data and contract data also called contract status
  • the local consensus node can determine the ledger data and contract data associated with the local consensus subchain from the first block based on the chain identifier of the local consensus subchain.
  • the first block contains an archiving configuration transaction
  • the archiving configuration transaction is determined to be a transaction associated with the local consensus subchain maintained by the local consensus node (also referred to as a transaction associated with the local consensus node)
  • an archiving task event is generated based on the archiving configuration transaction, which is equivalent to clearing the archiving task event from the first block to the chain identifier of the local consensus subchain.
  • the archiving task command indicated by the archiving task event is a ledger archiving command
  • the block data summary of the archived block on the local consensus subchain is sent to the core consensus node, and the core consensus node is used to package the first summary confirmation event of the block data summary into the second block, and write the second block into the main chain.
  • the local consensus node may include a task trigger, and when the main chain clearing synchronization component clears an archived task event that matches the local consensus subchain maintained by the local consensus node, the task trigger may detect the type of the cleared task event. If the task trigger detects that the type of the task event is an archived task event, and the archived task command indicated by the archived task event is the account book archive command corresponding to the local consensus data, The local consensus data on the local consensus subchain can be archived according to the instructions of the ledger archiving command.
  • the ledger archiving command is used to instruct the archiving of the transaction original text in the local consensus block on the local subchain, which is equivalent to archiving the ledger data in the local consensus block.
  • the business object can also specify the maximum block height of the local consensus block to be archived on the local consensus subchain, that is, the archiving command parameter of the ledger archiving command can include the chain identifier of the local consensus subchain to be archived, and the maximum block height of the local consensus block to be archived, and then the transaction parameters of the archiving configuration transaction determined based on the ledger archiving command can also include the chain identifier of the local consensus subchain to be archived, and the maximum block height of the local consensus block to be archived, so that the local consensus node can obtain the maximum block height of the local consensus block to be archived from the archiving command parameter of the ledger archiving command indicated by the archiving task event when clearing the first block to the archiving task event.
  • the local consensus node also includes a local consensus ledger database; the local consensus ledger database is used to store the ledger data of the local consensus block on the local consensus subchain, and the main chain subledger database is also used to store the ledger data associated with the local consensus node, and the stored ledger data is cleared from the synchronized global consensus block; the local consensus node determines the archived block on the local consensus subchain, including: the local consensus node determines the height of the block to be archived of the local consensus subchain based on the archiving command parameters indicated by the ledger archiving command, and the height of the block to be archived is the maximum block height of the local consensus block to be archived on the local consensus subchain; from the ledger data stored in the main chain subledger database, the archived block height of the local consensus subchain is determined; the height of the block to be archived is greater than the height of the archived block; the intermediate block height between the archived block height and the height of the block to be archived is obtained, and the local consensus ledger database
  • the archiving command parameters of the ledger archiving command include the maximum block height of the local consensus block to be archived, so that the local consensus node can use the maximum block height of the local consensus block to be archived in the archiving command parameters as the block height to be archived.
  • the maximum block height of the local consensus block to be archived on the local consensus subchain is the height value of the maximum block height of the local consensus block to be archived indicated by the ledger archiving command, which is different from the height value of the maximum block height of the local consensus block that has not been archived on the local consensus subchain.
  • the height value of the block height of the latest local consensus block on the local consensus subchain is 120, that is, the maximum block height of the local consensus block that has not been archived on the local consensus subchain is 120, and the ledger archiving command indicates that the local consensus blocks before the height value is 100 are archived, that is, the maximum block height of the local consensus blocks to be archived on the local consensus subchain is 100, so it can be determined that the height value of the block height to be archived in the local consensus subchain is 100.
  • the block height of the archived local consensus block on the local consensus subchain can be used as the archived block height; for example, if the height value of the block height of the archived local consensus block on the local consensus subchain is n, it means that the local consensus blocks with block height values of 0-n (including n) on the local consensus subchain have been archived, that is, the archived block height is n. It is understandable that the block height between the archived block height and the to-be-archived block height is the intermediate block height, which may not include the archived block height, but includes the to-be-archived block height.
  • the archiving command parameters indicated by the ledger archiving command include a block height of 100 to be archived, and the height of the archived block found in the main chain sub-ledger database is 80, then the local consensus block with a height value between 80 and 100 (excluding 80 and including 100) is used as the archived block.
  • the local consensus node determines the height of the block to be archived of the local consensus subchain based on the archiving command parameters indicated by the ledger archiving command; here, the local consensus node searches for the archived block height from the ledger data stored in the main chain subledger database. If the archived block height is not found, the local consensus block from the first local consensus block on the local consensus subchain to the local consensus block corresponding to the height of the block to be archived is used as the archived block.
  • the local consensus node can call the target archiving business contract on the local consensus subchain to determine the block data summary based on the block data of the archived block; then generate at least one first summary sending transaction based on the block data summary, and send the at least one first summary sending transaction to the core consensus node, so that the core consensus node generates a first summary confirmation event based on the at least one first summary sending transaction.
  • the target archiving business contract is a smart contract deployed on the local consensus subchain and is used to perform archiving business processing. It is understandable that when calling the target archiving business contract to determine the block data summary, each archived block can determine the corresponding block data summary. It is understandable that the block data summary corresponding to any archived block can include the block header hash, block hash, transaction type, timestamp and other information of the archived block, and the determined block data summary is used for subsequent core consensus nodes to verify whether the archived block is successfully backed up.
  • the first summary sending transaction is a summary sending transaction generated according to the block data summary, and the data volume of the generated first summary sending transaction is determined according to the data volume of the block data summary.
  • a first summary sending transaction can be used to send the target data volume of the block data summary, and then the block data summary of all archived blocks can be divided into at least one portion according to the target data volume, so as to determine a first summary sending transaction according to each portion of data, and obtain at least one first summary sending transaction corresponding to at least one portion.
  • the local consensus node can trigger the main chain forwarding on-chain component to send at least one first summary sending transaction to the core consensus node through a task trigger.
  • the core consensus node when the core consensus node generates the first summary confirmation event, it can generate a first summary confirmation transaction associated with the first summary confirmation event, and package the first summary confirmation transaction into the second block, so that the first summary confirmation event can be packaged into the second block; finally, the core consensus node writes the second block into the main chain.
  • the transaction parameters of the first summary confirmation transaction carry the chain identifier of the local consensus subchain of the first summary sending transaction, so that the local consensus node can perform data clearing based on the chain identifier.
  • the second block on the main chain is a different global consensus block from the first block, and the block height of the first block is less than the block height of the second block.
  • the block body of the local consensus block on the local consensus subchain can contain multiple transactions, each transaction has a corresponding transaction text, also known as the ledger number; the local consensus node can obtain the transaction text of all transactions in each local consensus block through the local consensus ledger database (as shown in the local consensus ledger database 314 in Figure 12), that is, the local consensus ledger database stores the transaction text of all transactions in the archived block, and then the transaction text of all transactions in the archived block can be determined from the local consensus ledger database; for example, the block height of the archived block is (80,100], then the transaction text of all transactions in multiple local consensus blocks corresponding to the height (80,100] is determined from the local consensus ledger database.
  • the local consensus node determines the ledger data to be backed up based on the transaction texts of all transactions in the archived block, and the transaction texts of all transactions in the archived block can be determined as the ledger data to be backed up.
  • the transaction texts of the transactions in the archived block and the block data summary of the archived block can also be determined as the ledger data to be backed up.
  • the remote backup device can be used to back up the local consensus data on the local consensus subchain.
  • the remote backup device can be some independent hardware storage devices, so as to reduce the waste of storage resources for archived data.
  • the remote backup device can back up the ledger data to be backed up, thereby realizing the backup of the ledger data to be backed up of the archived block, so as to transfer the local consensus data stored on the local consensus node to the remote backup device, reducing the storage pressure of the local consensus node.
  • the block data summary of the archived block is sent to the core consensus node again.
  • the target time period is a preset time for timeout retransmission. If the first summary confirmation event returned by the core consensus node is not cleared within the target time period, the block data summary will be re-uploaded to the core consensus node. For example, the target time period is 10 minutes, and the timing starts after the block data summary is sent to the core consensus node. If the local consensus node still has not cleared the first summary confirmation event through the main chain clearing synchronization component after 10 minutes, the block data summary of the archived block will be sent to the core consensus node again.
  • the local consensus node will back up the account data to be archived corresponding to the archived block to the remote backup device only after receiving the summary confirmation event returned by the core consensus node.
  • the reliability of the block data summary upload is guaranteed through the timeout retransmission mechanism, and the fault tolerance of the archiving process is improved.
  • S404 forwarding the first backup signature sent by the remote backup device to the core consensus node, where the core consensus node is used to determine that the ledger data to be backed up has been backed up to the remote backup device when it is determined that the first backup signature is generated by the remote backup device and the ledger backup data summary of the ledger backup information is consistent with the block data summary.
  • the remote backup device when the remote backup device uses the account book data to be backed up after the backup processing as the account book backup information, it can generate a first backup signature based on the account book backup information.
  • the first backup signature is used to indicate that the remote backup device has performed backup processing on the account book data to be backed up.
  • the remote backup device when it generates the first backup signature based on the account book backup information, it can be based on
  • the ledger backup information generates first remote backup confirmation information, and the first remote backup confirmation information is signed using a private key in the remote backup device to obtain first signature information, and a first backup signature is obtained based on the first remote backup confirmation information and the first signature information.
  • the first remote backup confirmation information is a summary of the ledger backup data determined based on the ledger backup information, and the method for determining the summary of the ledger backup data can be consistent with the method for determining the summary of the block data, so that the core consensus node can determine consistency based on the first remote backup confirmation information and the summary of the block data.
  • the core consensus node performs signature verification on the first backup signature, and can verify the first backup signature through the public key corresponding to the remote backup device, thereby ensuring that the first backup signature uploaded by the local consensus node is generated by the remote backup device and that the first backup signature has not been tampered with.
  • the core consensus node compares the ledger backup information corresponding to the first backup signature with the block data summary, and can verify that the ledger backup information indicated by the first backup signature has been backed up to the remote backup device.
  • the core consensus node can determine that the ledger backup data to be backed up has been backed up to the remote backup device.
  • the core consensus node can store the received block data summary and the first backup signature, so as to determine the remote backup device backed up by the local consensus block corresponding to the block data summary through the public key corresponding to the first backup signature, and then the remote backup ledger information of the local consensus block indicated by the block data summary can be found from the determined remote backup device.
  • the core consensus node determines that the account book data to be backed up has been successfully backed up to the remote backup device, it can also generate the first backup success information to notify the local consensus node that the account book data to be backed up has been successfully backed up to the remote backup device.
  • the local consensus node receives the first backup success information returned by the core consensus node, it clears the account book data to be backed up that has been backed up to the remote backup device; the first backup success information is generated by the core consensus node when it determines that the account book data to be backed up has been successfully backed up.
  • clearing the to-be-backed-up ledger data in the local consensus node that has been backed up to the remote backup device is equivalent to transferring some cold data in the local consensus node to the remote backup device for storage, thereby reducing the storage pressure on the local consensus node.
  • the local consensus node can clear the blocks synchronized from the main chain to the first backup success information through the component clearing synchronization component, and the first backup success information can be stored in the main chain sub-ledger database.
  • the first backup success information can include the maximum block height of the local consensus block that has been backed up to the remote backup device, and then when the next archiving task event for indicating the archiving of the ledger data is cleared, the block height of the archived local consensus block on the local consensus sub-chain can be found from the ledger data stored in the main chain sub-ledger database, and the next block archiving is performed based on the block height of the archived local consensus block found.
  • the maximum block height of the local consensus block that has been backed up to the remote backup device in the first backup success information is 100
  • the block height of the archived local consensus block on the current local consensus sub-chain is 100.
  • FIG. 15 is a flow chart of a ledger data archiving process provided by an embodiment of the present application. Schematic diagram of the process.
  • the local consensus node is synchronized from the main chain to the first block through the main chain clearing synchronization component (step S501a), and clears the account data and archiving task events related to the local consensus node from the first block.
  • the task trigger detects that the clearing synchronization component clears the archiving task event, it detects the type of the archiving task event.
  • the task trigger triggers the local chain transaction execution component (step S502a), so that the local chain transaction execution component can call the corresponding target business archiving contract to determine the block data summary of the local consensus block (also called the archiving block) to be archived.
  • FIG 16 is a flow chart of a ledger data archiving process provided by an embodiment of the present application.
  • the task trigger triggers the main chain forwarding chain component (step S501b), so that the main chain forwarding chain component sends the block data summary to the core consensus network.
  • the block data summary can be placed in at least one first summary sending transaction, so that the block data summary is sent to the core consensus network in the form of a transaction.
  • the local consensus node synchronizes the second block from the main chain through the main chain clearing synchronization component (step S501c), and clears the ledger data related to the local consensus node from the second block to clear the first summary confirmation event, and when the main chain clearing synchronization component clears the first summary confirmation event, the task trigger trigger triggers the local chain transaction execution component (step S502c), so that the local chain transaction execution component calls the corresponding target archiving business contract to determine the ledger data to be backed up corresponding to the archiving task event; and then the task trigger sends the ledger data to be backed up to the remote backup device (step S503c).
  • the remote backup device After the remote backup device performs backup processing on the ledger data to be backed up, it can also return a first backup signature to the local consensus node.
  • the local consensus node receives the first backup signature, it triggers the main chain forwarding chain component through the task trigger (step S504c), so that the main chain forwarding chain component uploads the first backup signature to the core consensus network.
  • the core consensus nodes in the core consensus network perform a consistency comparison based on the first backup signature and the block data summary. When the comparison is successful, it is determined that the backup of the ledger data to be backed up is successful, and the first backup success information can be generated.
  • the local consensus node can receive the first backup success information sent by the core consensus node in the core consensus network, and then clear the successfully backed up account data to be backed up.
  • the first backup success information can be packaged into the fourth block by the core consensus node, and then the local consensus node can be synchronized from the main chain to the fourth block through the main chain clearing synchronization component, and clear the account data related to the local consensus node from the fourth block.
  • the local consensus node detects that the main chain clearing synchronization component has cleared the first backup success information through the task trigger, it triggers the local chain transaction execution component to enable the local chain transaction execution component to call the corresponding target archiving business contract to clear the account data to be backed up to the remote backup device.
  • the embodiment of the present application proposes a multi-layer blockchain data processing method.
  • Figure 18, is a flow chart of a multi-layer blockchain data processing method provided by the embodiment of the present application.
  • the method is executed by a local consensus node and includes steps S601 to S604.
  • the first block When synchronizing from the main chain to the first block, clear the archiving task events of the local consensus subchain from the first block; the first block includes an archiving configuration transaction associated with the archiving task event; the archiving configuration transaction is determined by the archiving task command triggered by the business object; the archiving task command is used to archive the local consensus data on the local consensus subchain.
  • step S601 may refer to the relevant description of step S401, which will not be elaborated here.
  • S602 When the archiving task command indicated by the archiving task event is a contract archiving command, The command sends the contract data summary of the archived contract on the local consensus subchain to the core consensus node.
  • the core consensus node is used to package the second summary confirmation event of the contract data summary pair into the third block and write the third block into the main chain.
  • the task trigger in the local consensus node triggers the main chain clearing synchronization component to clear the task events that match the local consensus sub-chain maintained by the local consensus node.
  • the task trigger can detect the type corresponding to the cleared task event. If the task trigger detects that the task event is an archived task event, and the archived task command indicated by the archived task event is the contract archive command corresponding to the local consensus data, the local consensus data (such as the contract data of the contract) on the local consensus sub-chain is archived according to the instructions of the contract archive command.
  • the contract archiving command corresponding to the local consensus data is used to instruct the contract data on the local consensus subchain to be archived. Therefore, when the business object triggers the contract archiving command, it specifies the chain identifier of the local consensus subchain requested for archiving, the contract identifier of the contract to be archived on the local consensus subchain, and the maximum contract index value of the contract to be archived; therefore, the command parameters of the contract archiving command include the chain identifier of the local consensus subchain requested for archiving, the contract identifier of the contract to be archived on the local consensus subchain, and the maximum contract index value of the contract to be archived; and then the transaction parameters of the archiving configuration transaction determined based on the contract archiving command include the chain identifier requested for archiving, the contract identifier of the contract to be archived, and the maximum contract index value of the contract to be archived; thus, when the local consensus node clears from the first block including the archiving configuration transaction to the archiving task
  • the contract identifier of the contract to be archived in the contract archiving command can be the contract call address, contract identification number or contract name, etc., which is not limited here.
  • the contract index value is the data sequence index inside the contract, such as 0, 1, 2, 3 and other serial numbers.
  • the local consensus node can determine the contract to be archived on the local consensus subchain based on the contract identifier indicated by the archiving command parameter in the contract archiving command, and use the contract to be archived on the local consensus subchain as the archived contract.
  • the main chain sub-ledger database is also used to store contract data associated with the local consensus node, and the stored contract data is cleared from the synchronized global consensus block; thus, the local consensus node sends the contract data summary of the archived contract on the local consensus sub-chain to the core consensus node based on the contract archiving command, including: the local consensus node determines the contract index value to be archived in the archived contract based on the archiving command parameters indicated by the contract archiving command, and the contract index value to be archived is the maximum contract index value to be archived in the archived contract; from the ledger data stored in the main chain sub-ledger database, search for the archived contract index value in the archived contract; the contract index value to be archived is greater than the archived contract index value; based on the contract index value between the archived contract index value and the contract index value to be archived, determine the contract data to be backed up in the archived contract on the local consensus sub-chain; send the contract data summary information of the contract data to
  • the contract state of the contract can be updated once, and the contract state can be the state value of the contract parameter represented by the key-value pair in the contract, and the contract index value of the contract state is determined; when the contract is called for business processing next time, the contract state is updated again, and the contract index value of the updated contract state is determined, and the contract index value determined this time is 1 greater than the contract index value determined last time.
  • the contract index value of the contract state also called contract data
  • the archive command parameters of the contract archive command include the parameters for indicating the contract to be archived on the local consensus subchain.
  • the maximum contract index value of the archived contract can be used as the contract index value to be archived. It can be understood that the maximum contract index value of the contract to be archived on the local consensus subchain is the maximum contract index value to be archived indicated by the contract archiving command, which is different from the maximum contract index value that has not been archived in the archived contract on the local consensus subchain.
  • the current maximum contract index value on the local consensus subchain is 50, that is, the maximum contract index value that has not been archived in the archived contract on the local consensus subchain is 50, and the contract archiving command indicates that the contract index value before the contract index value 30 is to be archived, that is, the maximum contract index value of the contract to be archived in the archived contract on the local consensus subchain is 30, so it can be determined that the contract index value to be archived is 30.
  • the contract index value between the archived contract index value and the contract index value to be archived may not include the archived contract index value, but include the contract index value to be archived; here, the determined contract index value between the archived contract index value and the contract index value to be archived can also be called the archived contract index value in the archived contract.
  • the contract data corresponding to the contract index values between 40-50 (excluding 40 and including 50) will be used as the contract data to be archived in the archived contract.
  • the archived contract index value on the local consensus sub-chain is not found in the main chain sub-ledger database, it means that the contract data of the archived contract on the local consensus sub-chain is not currently archived, and then the contract data in the archived contract can be archived starting from the difference between the index value corresponding to the first contract in the archived contract on the local consensus sub-chain and 1 (such as the contract index value 0).
  • the archived contract index value can be recorded as a specified value (for example, 0), so that the contract data corresponding to the contract index value to be archived in the archived contract on the local consensus sub-chain before the contract data to be archived are all used as contract data to be archived.
  • the maximum contract index value included in the archiving command parameters indicated by the contract archiving command is 50, that is, the contract index value to be archived is 50, and the contract index value of the archived local consensus block is not found in the main chain sub-ledger database, it means that the block on the local consensus sub-chain has not been archived, and the contract data corresponding to the contract index value between 0-50 can be used as the contract data to be archived in the archived contract.
  • the local consensus node can call the target archiving business contract on the local consensus subchain to determine the contract data summary based on the contract data to be archived in the archiving contract; generate at least one second summary sending transaction based on the contract data summary, and send at least one second summary sending transaction to the core consensus node, so that the core consensus node generates a second summary confirmation event based on the at least one second summary sending transaction.
  • the second summary sending transaction can be a summary sending transaction generated according to the contract data summary, and the data volume of the generated second summary sending transaction can be determined according to the data volume of the contract data summary.
  • a second summary sending transaction can be used for the target data volume of the contract data summary, and then the contract data summary can be divided into at least one portion according to the target data volume, so as to determine a second summary sending transaction according to each portion of data, and obtain at least one second summary sending transaction corresponding to at least one portion.
  • the local consensus node can trigger the main chain forwarding on-chain component to send at least one second summary sending transaction to the core consensus node through a task trigger.
  • the core consensus node After receiving all the second summary sending transactions, the core consensus node generates a second summary confirmation event.
  • the second summary confirmation event is used to indicate that the core consensus node has received the block data summary on the local consensus subchain.
  • the core consensus node when it generates the second summary confirmation event, it can generate a second summary confirmation transaction associated with the second summary confirmation event, and package the second summary confirmation transaction into the third block, so that the second summary confirmation event can be packaged into the third block; finally, the core consensus node writes the third block into the main chain.
  • the transaction parameters of the second summary confirmation transaction carry the chain identifier of the local consensus subchain of the second summary sending transaction, so that the local consensus node can perform data clearing based on the chain identifier.
  • the third block and the first block on the main chain can be different global consensus blocks, and the block height of the first block is less than the block height of the third block.
  • the business object can trigger the contract archiving command for the registered contract on the main chain.
  • the core consensus node registers the contract on the local consensus subchain on the main chain, it checks the description file of the contract to be registered to confirm whether the contract to be registered implements the archiving interface. If the contract to be registered does not implement the archiving interface, the core consensus node will not be able to archive the contract on the local consensus subchain that does not implement the archiving interface.
  • each archiving task event indicated by the archiving configuration exchange can only be archived for one contract.
  • the local consensus node can execute the contract archiving task for each contract in serial.
  • the local consensus node can store the contract data on the local consensus subchain through the local consensus ledger database, and then determine the contract data to be archived from the local consensus ledger database; for example, the contract identifier of the archived contract is M1, and the contract data to be archived in the archived contract is the contract data corresponding to the contract index value (30,150], and then the contract data corresponding to the contract index value (30,150] can be determined from the contract data with the contract identifier M1 in the local consensus ledger database.
  • the contract identifier of the archived contract is M1
  • the contract data to be archived in the archived contract is the contract data corresponding to the contract index value (30,150]
  • the contract data corresponding to the contract index value (30,150] can be determined from the contract data with the contract identifier M1 in the local consensus ledger database.
  • the contract data to be backed up can be determined based on the contract data to be archived in the archived contract.
  • the contract data to be archived in the archive contract is determined as the contract data to be backed up.
  • the remote backup device can back up and store the contract data to be backed up, thereby realizing the backup of the contract data to be backed up corresponding to the archived block, so as to transfer the local consensus data stored on the local consensus node to the remote backup device, reducing the storage pressure of the local consensus node.
  • the target time period is 10 minutes, starting from the time when the contract data summary is sent to the core consensus node. If the local consensus node has not obtained the second summary confirmation event through the main chain clearing synchronization component after 10 minutes, the block data summary of the archived block will be sent to the core consensus node again. It is understandable that during the archiving process, the local consensus node will back up the contract data to be backed up to the remote backup device only after receiving the summary confirmation event returned by the core consensus node.
  • the timeout retransmission mechanism ensures the reliability of the contract data summary upload and improves the fault tolerance of the archiving process.
  • the core consensus node is used to determine that the contract data to be backed up has been backed up to the remote backup device when it is determined that the second backup signature is generated by the remote backup device and the account backup data summary of the contract backup information is consistent with the contract data summary.
  • the remote backup device when the remote backup device uses the backup-processed contract data to be backed up as the contract backup information, it can generate second remote backup signature information based on the contract backup information.
  • the second remote backup signature information can be used to indicate that the remote backup device has backed up the contract data to be backed up.
  • the remote backup device when it generates the second backup signature based on the contract backup information, it can generate the second remote backup confirmation information based on the contract backup information, use the private key in the remote backup device to sign the second remote backup confirmation information to obtain the second signature information, and obtain the second backup signature based on the second remote backup confirmation information and the second signature information.
  • the second remote backup confirmation information is a contract backup data summary determined based on the contract backup information, and the method for determining the contract backup data summary can be consistent with the method for determining the above-mentioned contract data summary, so that the core consensus node can determine the consistency based on the second remote backup confirmation information and the contract data summary.
  • the core consensus node can verify the signature of the second backup signature by using the public key corresponding to the remote backup device, thereby ensuring that the second backup signature uploaded by the local consensus node is generated by a trusted remote backup device and that the second backup signature has not been tampered with.
  • the core consensus node compares the contract backup information corresponding to the second backup signature with the contract data summary, and can verify that the contract backup information indicated by the second backup signature has been backed up to the remote backup device.
  • the core consensus node can determine that the contract data to be backed up has been backed up to the remote backup device.
  • the core consensus node can store the received contract data summary and the second backup signature, so as to determine the remote backup device to which the contract data corresponding to the contract data summary is backed up through the public key corresponding to the second backup signature, and then find the contract data corresponding to the contract data summary from the determined remote backup device. Remote backup of contract information.
  • the core consensus node can also generate a second backup success message when determining that the contract data to be backed up has been successfully backed up to the remote backup device, to notify the local consensus node that the contract data to be backed up has been successfully backed up to the remote backup device.
  • the local consensus node receives the second backup success message returned by the core consensus node, it clears the contract data to be backed up that has been backed up to the remote backup device; wherein, the second backup success message is generated by the core consensus node when determining that the contract data to be backed up has been successfully backed up to the remote backup device.
  • the local consensus node can be synchronized from the main chain to the first block through the main chain clearing synchronization component, and clear the account book data related to the local consensus node.
  • the task trigger detects that the clearing synchronization component clears the archiving task event, it can judge the type of the detected archiving task event. If it is judged that the archiving task command indicated by the archiving task event is a contract archiving command, the task trigger triggers the local chain transaction execution component to call the corresponding target business archiving contract to determine the block data summary of the contract to be archived. Then, the task trigger can trigger the main chain forwarding chain component, so that the main chain forwarding chain component can send the contract data summary to the core consensus network.
  • the contract data summary can be placed in at least one second summary sending transaction, so that the contract data summary is sent to the core consensus network in the form of a transaction.
  • the local consensus node can be synchronized from the main chain to the third block through the main chain clearing synchronization component.
  • the task trigger can trigger the local chain transaction execution component, so that the local chain transaction execution component can call the corresponding target archiving business contract to determine the contract data to be backed up corresponding to the archiving task event, and then the task trigger can send the contract data to be backed up to the remote backup device.
  • the remote backup device After the remote backup device performs backup processing on the contract data to be backed up, it can also return a second backup signature to the local consensus node.
  • the local consensus node When the local consensus node receives the second backup signature, it can trigger the main chain forwarding chain component through the task trigger, and the main chain forwarding chain component can upload the second backup signature to the core consensus network.
  • the core consensus node in the core consensus network can perform consistency comparison based on the second backup signature and the contract data summary. When the comparison is successful, it can be determined that the backup of the contract data to be backed up is successful, and then the second backup success information can be generated.
  • the local consensus node can receive the second backup success information sent by the core consensus node, and then clear the backup contract data based on the second backup success information.
  • the second backup success information can be packaged into the fifth block by the core consensus node, and then the local consensus node can be synchronized from the main chain to the fifth block through the main chain clearing synchronization component, and clear the account data related to the local consensus node from the fifth block.
  • the task trigger can trigger the local chain transaction execution component, so that the local chain transaction execution component calls the corresponding target archiving business contract to clear the backup contract data.
  • the local consensus node can clear the blocks synchronized from the main chain through the component clearing synchronization component to obtain the second backup success information
  • the second backup success information can be stored in the main chain sub-ledger database.
  • the second backup success information can include the contract identifier corresponding to the to-be-backed-up contract data that has been backed up to the remote backup device and the maximum contract index value that has been backed up in the contract corresponding to the contract identifier.
  • the maximum contract index value indicated by the success message is equivalent to the contract index value that has been archived in the contract (such as the contract with the contract identifier M1) indicated by the second backup success message on the current local consensus subchain.
  • the archived contract index value in the contract to be archived on the local consensus subchain can be found from the account data stored in the main chain sub-account database, and the archived contract index value in the contract to be archived on the local consensus subchain found is used as the archived contract index value. For example, if the maximum contract index value of the contract M1 corresponding to the contract data to be backed up that has been backed up to the remote backup device contained in the second backup success message is 100, then the archived contract index value in the contract M1 on the current local consensus subchain is 100.
  • the summary corresponding to the local consensus data to be archived (such as the contract data summary) is sent to the core consensus node corresponding to the main chain; and when the summary confirmation event is cleared from the second block through the main chain clearing synchronization component, the local consensus data to be archived (such as the contract data to be backed up) is sent to the remote backup device for backup; then when the local consensus node receives the second backup signature returned by the remote backup device, the second backup signature is sent to the core consensus node, so that the core consensus node determines that the local consensus data to be archived has been backed up to the remote backup device when the summary is successfully compared with the second remote backup signature.
  • the archiving configuration transaction can be received by the core consensus node corresponding to the main chain, and then the archiving of the local consensus data on the local consensus subchain used for regional business processing can be controlled, so that the transactions related to the business nodes in different regions can be archived separately, thereby improving the controllability of the data archiving process of the blockchain and the security of data archiving through collaborative archiving between multi-layer blockchains.
  • the core consensus node can audit the archiving process of local consensus data to improve the controllability and data security of the archiving process of local consensus data.
  • the archiving configuration transaction submitted by the business object for the archiving task command when the archiving configuration transaction submitted by the business object for the archiving task command is packaged into the first block through the core consensus node and chained to the main chain, it can ensure that the local consensus node deployed in the local consensus network of the multi-layer blockchain is synchronized from the main chain maintained by the core consensus node to the first block packaged with the archiving configuration transaction, and then the archiving task event associated with the archiving task command is cleared from the first block, and then the archiving task command indicated by the archiving task event can be obtained.
  • the embodiment of the present application can control the local consensus node to archive its local local consensus data (for example, the contract status data stored locally by the local consensus node itself) according to the currently acquired archiving task command through the mutual cooperation between the multi-layer blockchains, so as to achieve the controllability of data archiving of the local consensus data on the local consensus subchain.
  • its local local consensus data for example, the contract status data stored locally by the local consensus node itself
  • the local consensus node uploads the summary of its locally stored contract data to the main chain through the core consensus node before backing up its local contract data to the remote backup device, rather than directly uploading its locally stored contract data to the main chain through the core consensus node, it can ensure that the contract data executed locally by the local consensus node itself will not be synchronized by other business nodes, so that when archiving the local consensus data on the local consensus subchain, the privacy and security of the transactions executed on the local consensus node can be ensured.
  • the core consensus node can also compare the summary submitted by the local consensus node with the second backup signature, so that during the archiving process of the local consensus data on the local consensus subchain, the data security of the ledger backup information backed up on the remote backup device can be ensured.
  • the embodiment of the present application proposes a multi-layer blockchain data processing method.
  • Figure 19 is a flow chart of a multi-layer blockchain data processing method provided by the embodiment of the present application. The method is executed by the core consensus node, and the multi-layer blockchain data processing method includes steps S801 to S804, and each step is described below.
  • the local consensus node is used to clear the archiving task events of the local consensus subchain from the first block; the first block includes an archiving configuration transaction associated with the archiving task event; the archiving configuration transaction is determined by the archiving task command triggered by the business object; the archiving task command is used to archive the local consensus data on the local consensus subchain.
  • the archived block is a local consensus block to be archived on the local consensus subchain determined by the local consensus node based on the ledger archiving command when the archiving task command indicated by the archiving task event is a ledger archiving command.
  • the local consensus node is also used to determine the ledger data to be backed up when the first summary confirmation event is cleared from the second block, and send the ledger data to be backed up to the remote backup device of the multi-layer chain network.
  • the first backup signature is information returned by the remote backup device based on the ledger backup information, and the first backup signature is forwarded through the local consensus node.
  • the ledger backup information is information obtained by the remote backup device when backing up the ledger data to be backed up.
  • step S801 to step S804 is opposite to the description corresponding to step S601 to step S604, the embodiment of the present application will not be repeated here.
  • the consensus module 20-12 is configured to broadcast the local consensus block to the local verification node, and the local verification node is used to obtain the voting consensus result corresponding to the transaction execution result of the local consensus transaction when the synchronized block height is greater than or equal to the main chain binding height and the synchronized read data set is consistent with the main chain read data set.
  • the local verification node is a consensus node other than the local consensus node in the local consensus network;
  • the consensus module 20-12 also includes: a data review unit 20-121 and a block consensus unit 20-122.
  • the data review unit 20-121 includes:
  • the contract calling subunit 20-1211 is configured to call the local consensus business contract on the local consensus subchain to perform data review
  • the data comparison subunit 20-1214 is configured to use the key-value pair in the to-be-confirmed read data set as the first key-value pair, and the key-value pair of the main chain read data set as the second key-value pair, and when the first key-value pair and the second key-value pair are consistent, execute the local consensus transaction in the local consensus block to obtain a transaction execution result.
  • the block consensus unit 20-122 is configured to cancel the review of the main chain read data set when the height of the block to be confirmed is lower than the main chain binding height;
  • the block consensus unit 20-122 is also configured to cancel the execution of the local consensus transaction when the first key-value pair is inconsistent with the second key-value pair.
  • the packaging module 20-11 also includes:
  • the synchronization request sending unit 20-112 is configured to send the main chain clearing synchronization request to the core consensus node; the main chain clearing synchronization request is used to instruct the core consensus node to determine the global consensus block with a block height higher than the first global consensus block as a global consensus block on the main chain that has not been synchronized to the local consensus node, and select a global block to be synchronized from the global consensus blocks that have not been synchronized to the local consensus node;
  • the data receiving unit 20-113 is configured to receive the global block to be synchronized returned by the core consensus node, and use the global block to be synchronized as the second global consensus block.
  • the packaging module 20-11 also includes:
  • the binding height determination unit 20-114 is configured to obtain the maximum global block height and the global consensus block corresponding to the maximum global block height from the main chain through the core consensus node when packaging the local consensus transaction; use the global consensus block corresponding to the maximum global block height as the first global consensus block, and use the maximum global block height as the main chain binding height.
  • processing module 20-13 also includes:
  • a synchronization request acquisition unit 20-131 is configured to acquire a subchain clearing synchronization request sent by a local business node;
  • the local business node includes a local chain subledger database, the subchain clearing synchronization request carries the local block height synchronized by the local business node from the local consensus subchain, the local consensus subchain is the blockchain of the local consensus node, and the local block height is the block height of the local consensus block;
  • the local block selection unit 20-132 is configured to determine the local consensus block whose block height on the local consensus subchain is greater than the local block height as a local consensus block that has not been synchronized to the local business node, and select the local consensus block from the local consensus subchain. Selecting a local block to be synchronized from the local consensus blocks that have not been synchronized to the local business node;
  • the local block sending unit 20-133 is configured to obtain the local contract status of the local block to be synchronized, and return the local block to be synchronized and the local contract status to the local business node, and the local business node is used to write the local block to be synchronized and the local contract status into the local chain sub-ledger database; the local contract status is a set of read data read by executing the local consensus transaction in the local block to be synchronized, and the local consensus transaction is executed by the local consensus business contract on the local consensus sub-chain of the local consensus network.
  • the local block selection unit 20-132 is also configured to obtain the local consensus block corresponding to the maximum local block height from the local consensus subchain when the maximum local block height on the local consensus subchain is equal to or less than the local block height; and use the local consensus block corresponding to the maximum local block height as the local block to be synchronized.
  • the data receiving unit 20-113 is further configured to synchronize a target consensus block including a registration transaction from the main chain, wherein the registration transaction is a business transaction that applies to the core consensus node to register the local consensus subchain, and a configuration transaction corresponding to the registration transaction is written in the target consensus block, and the configuration transaction carries configuration information;
  • the packaging module 20-11 also includes:
  • the block creation subunit 20-115 is configured to obtain the configuration information from the target consensus block, and when the configuration information is consistent with the information configured by the local consensus node, create a genesis block in the local consensus network; and start the local consensus subchain based on the genesis block.
  • the processing module 20-13 is also configured to perform transaction aggregation processing on the execution results corresponding to the local consensus transactions to obtain aggregated transaction information; generate an information on-chain transaction carrying the aggregated transaction information; call the main chain forwarding on-chain component to generate a main chain on-chain request carrying the information on-chain transaction; and send the main chain on-chain request to the core consensus node, where the main chain on-chain request is used to instruct the core consensus node to write the information on-chain transaction into the main chain.
  • the first blockchain data processing device 20 - 1 further includes: a main chain synchronization module 20 - 81 , an archive data processing module 20 - 82 , a data backup module 20 - 83 , and an information receiving module 20 - 84 ;
  • the main chain synchronization module 20-81 is configured to clear the archiving task event of the local consensus subchain from the first block when synchronizing from the main chain to the first block;
  • the first block includes an archiving configuration transaction associated with the archiving task event;
  • the archiving configuration transaction is determined by an archiving task command triggered by a business object;
  • the archiving task command is used to archive the local consensus data on the local consensus subchain;
  • the archiving data processing module 20-82 is configured to send the block data summary of the archived block on the local consensus subchain to the core consensus node based on the account archiving command when the archiving task command indicated by the archiving task event is a ledger archiving command, and the core consensus node is used to package the first summary confirmation event of the block data summary into a second block, and write the second block into the main chain;
  • the data backup module 20-83 is configured to synchronize the second block from the main chain, determine the ledger data to be backed up based on the transaction original text in the archived block when the first summary confirmation event is cleared from the second block, and send the ledger data to be backed up to a remote backup device connected to the multi-layer chain network, wherein the remote backup device is used to back up the ledger data to be backed up to obtain ledger backup information;
  • the information receiving module 20-84 is configured to forward the first backup signature sent by the remote backup device to the core consensus node, and the core consensus node is used to determine that the first backup signature has been generated by the remote backup device and the account backup data summary of the account backup information is consistent with the block data summary.
  • the account book data to be backed up is backed up to the remote backup device.
  • the local consensus node includes a local consensus ledger database and a main chain sub-ledger database; the local consensus ledger database is used to store the ledger data of the local consensus block on the local consensus sub-chain, and the main chain sub-ledger database is used to store the ledger data associated with the local consensus node, and the stored ledger data is cleared from the synchronized global consensus block;
  • the archive data processing module 20-82 includes: a command parsing unit 20-821, a data search unit 20-822, and a backup data determination unit 20-823;
  • the command parsing unit 20-821 is configured to read the to-be-archived block height of the local consensus subchain from the archiving command parameter indicated by the ledger archiving command, wherein the to-be-archived block height is the maximum block height of the to-be-archived local consensus block on the local consensus subchain;
  • the data search unit 20-822 is configured to determine the archived block height of the local consensus sub-chain from the ledger data stored in the main chain sub-ledger database; the height of the block to be archived is greater than the archived block height;
  • the backup data determination unit 20-823 is configured to obtain an intermediate block height between the archived block height and the to-be-archived block height, and use the local consensus block corresponding to the intermediate block height as the archived block.
  • the archive data processing module 20-82 includes: a contract calling unit 20-824 and an information sending unit 20-825;
  • the information sending unit 20-825 is configured to generate at least one first summary sending transaction based on the block data summary; send at least one first summary sending transaction to the core consensus node, and the core consensus node is used to generate the first summary confirmation event based on at least one first summary sending transaction.
  • the archive data processing module 20-82 is further configured to, when the archive task command indicated by the archive task event is a contract archive command, send the contract data summary of the archive contract on the local consensus subchain to the core consensus node based on the contract archive command, and the core consensus node is used to package the second summary confirmation event of the contract data summary pair into a third block, and write the third block into the main chain;
  • the information receiving module 20-84 is also configured to forward the second backup signature sent by the remote backup device to the core consensus node, and the core consensus node is used to determine that the contract data to be backed up has been backed up to the remote backup device when it is determined that the second backup signature is generated by the remote backup device and the account backup data summary of the contract backup information is consistent with the contract data summary.
  • the archive data processing module 20-82 is also configured to determine the archive contract from the local consensus sub-chain based on the contract identifier indicated by the archive command parameter in the contract archive command.
  • the main chain sub-ledger database is also used to store contract data associated with the local consensus node.
  • the contract data is cleared from the synchronized global consensus block;
  • the command parsing unit 20-821 is further configured to read the contract index value to be archived in the archived contract from the archive command parameter, wherein the contract index value to be archived is the maximum contract index value to be archived in the archived contract;
  • the data search unit 20-822 is further configured to search for an archived contract index value in the archived contract from the account data stored in the main chain sub-account database; the index value of the contract to be archived is greater than the index value of the archived contract;
  • the backup data determination unit 20-823 is also configured to determine the contract data to be backed up in the archived contract on the local consensus subchain based on the contract index value between the archived contract index value and the contract index value to be archived.
  • the contract calling unit 20-824 is further configured to call the target archiving business contract on the local consensus subchain to process the contract data to be backed up of the archiving contract to obtain the contract data summary;
  • the information sending unit 20-825 is also configured to generate at least one second summary sending transaction based on the contract data summary; send the at least one second summary sending transaction to the core consensus node, and the core consensus node is used to generate the second summary confirmation event based on the at least one second summary sending transaction.
  • the information sending unit 20-825 is also configured to clear the contract data to be backed up that has been backed up to the remote backup device when receiving the second backup success information returned by the core consensus node; the second backup success information is generated by the core consensus node when it determines that the contract data to be backed up has been successfully backed up.
  • the packaging module 20-11, the consensus module 20-12, the processing module 20-13, the main chain synchronization module 20-81, the archive data processing module 20-82, the data backup module 20-83 and the information receiving module 20-84 can be referred to the above description, and will not be further described here.
  • the description of the same beneficial effects obtained by using the same method will not be repeated.
  • FIG 21 is a structural diagram of a blockchain data processing device provided in an embodiment of the present application.
  • the second blockchain data processing device 21-1 can be applied to the core consensus node.
  • the second blockchain data processing device 21-1 can be a computer program (including program code) running in the blockchain node.
  • the second blockchain data processing device 21-1 can be an application software; it can be understood that the second blockchain data processing device 21-1 can be used to execute the corresponding steps in the method provided in the embodiment of the present application.
  • the second blockchain data processing device 21-1 may include: an acquisition module 21-21, a determination module 21-22, and a data return module 21-23;
  • the determination module 21-22 is configured to determine, from the main chain, a global consensus block whose block height is greater than the block height of the third global consensus block as the first global consensus block that has not been synchronized to the local consensus node;
  • the acquisition module 21-21 is further configured to acquire the first global contract state of the first global consensus block from the main chain;
  • the first global contract state is a set of read data read when executing the global consensus transaction in the first global consensus block;
  • the second blockchain data processing device 21 - 1 further includes: a data synchronization module 21 - 91 , an information confirmation module 21 - 92 , and an information verification module 21 - 93 ;
  • the data synchronization module 21-91 is configured to synchronize the first block to the local consensus node of the local consensus subchain, wherein the local consensus node is used to clear the archiving task event of the local consensus subchain from the first block; the first block includes an archiving configuration transaction associated with the archiving task event; the archiving configuration transaction is determined by the archiving task command triggered by the business object; the archiving task command is used to archive the local consensus data on the local consensus subchain;
  • the information confirmation module 21-92 is configured to receive the block data summary of the archived block sent by the local consensus node, package the first summary confirmation event of the block data summary into the second block, and write the second block into the main chain;
  • the archived block is the local consensus block to be archived on the local consensus subchain determined by the local consensus node based on the ledger archiving command when the archiving task command indicated by the archiving task event is a ledger archiving command;
  • the data synchronization module 21-91 is configured to synchronize the second block to the local consensus node, and the local consensus node is further used to determine the ledger data to be backed up when the first summary confirmation event is cleared from the second block, and send the ledger data to be backed up to a remote backup device of the multi-layer chain network;
  • the information verification module 21-93 is configured to receive a first backup signature returned by the local consensus node, and when it is determined that the first backup signature is generated by the remote backup device and the ledger backup data summary of the ledger backup information is consistent with the block data summary, it is determined that the ledger data to be backed up has been successfully backed up to the remote backup device; the first backup signature is information returned by the remote backup device based on the ledger backup information, and the first backup signature is forwarded through the local consensus node, and the ledger backup information is information obtained by the remote backup device when backing up the ledger data to be backed up.
  • the electronic device 1200 can be a terminal or a server, which will not be limited here. It can be understood that the electronic device can be a local consensus node and a core consensus node.
  • the embodiment of the present application takes the electronic device as a server as an example for explanation, and the electronic device 1200 may include: a processor 1201, a network interface 1204 and a memory 1205.
  • the electronic device 1200 may also include: a user interface 1203, and at least one communication bus 1202. Among them, the communication bus 1202 is used to realize the connection and communication between these components.
  • the user interface 1203 may also include a standard wired interface and a wireless interface.
  • the network interface 1204 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the memory 1205 may be a high-speed random access memory (Random Access Memory, RAM) memory, or a non-volatile memory (non-volatile memory), such as at least one disk memory.
  • the memory 1205 may also be at least one storage device located away from the aforementioned processor 1201. As shown in FIG. 22 , the memory 1205 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application.
  • the network interface 1204 in the electronic device 1200 can also provide a network communication function.
  • the network interface 1204 can provide a network communication function;
  • the user interface 1203 is mainly used to provide an input interface for the user;
  • the processor 1201 can be used to call the device control application stored in the memory 1205 to execute the blockchain data processing method applied to the local consensus node or the blockchain data processing method applied to the core consensus node provided in the embodiment of the present application.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the first blockchain data processing device or the second blockchain data processing device, and the computer program includes computer instructions.
  • the processor executes the computer instructions, it can execute the blockchain data processing method applied to the local consensus node or the blockchain data processing method applied to the core consensus node provided in the embodiment of the present application.
  • the computer instructions can be deployed on an electronic device for execution, or on multiple electronic devices located in one location, or on multiple electronic devices distributed in multiple locations and interconnected by a communication network. Multiple electronic devices distributed in multiple locations and interconnected by a communication network can constitute a blockchain system.
  • the embodiment of the present application also provides a computer program product or a computer program, which may include computer instructions, which may be stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, so that the electronic device executes the blockchain data processing method applied to the local consensus node or the blockchain data processing method applied to the core consensus node provided in the embodiment of the present application.
  • the blockchain data processing system 23-3 may include a local consensus node 3a and a core consensus node 3b; wherein the local consensus node 3a may be a local consensus node in a local consensus network as described in an embodiment of the present application. wherein the core consensus node 3b may be a core consensus node in a core consensus network as described in an embodiment of the present application.
  • the modules in the device of the embodiment of the present application can be merged, divided and deleted according to actual needs.
  • the storage medium can be a disk, an optical disk, a read-only memory (ROM) or a RAM, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品，该方法包括：将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块；主链绑定高度为从核心共识节点所维护的主链上所同步到的第一全局共识区块的区块高度；主链读数据集合是从第一全局合约状态中所清分到的、且用于执行局部共识交易；将局部共识区块广播给局部验证节点，局部验证节点用于在所同步到的区块高度大于或等于主链绑定高度、以及所同步到的读数据集合与主链读数据集合一致时，获取局部共识交易的交易执行结果所对应的投票共识结果；在基于局部验证节点返回的投票共识结果确定达成共识时，将局部共识区块上链至局部共识网络对应的局部共识子链。

Description

一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品
相关申请的交叉引用
本申请基于申请号为202211637945.5、申请日为2022年12月15日的中国专利申请，以及申请号为202211637944.0、申请日为2022年12月15日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及区块链技术领域，尤其涉及一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品。
背景技术
在由业务网络和核心共识网络所构成的单区块链中，位于业务网络中的业务节点需要依赖于部署在核心共识网络中的共识节点来进行交易打包、区块共识。所以，单区块链系统的业务网络中所部署的业务节点自身并不参与区块共识，而是作为单区块链系统所涉及的单一链的账本同步工具。
发明人在实践中发现，由于单区块链系统所涉及的区块链为单一链，所以，由不同业务方通过不同业务节点所提交的业务交易统一提交到核心共识网络，从而可以由核心共识网络中的共识节点(例如，打包节点)对获取到的这些交易进行统一的交易打包，导致在该单一链上参与共识的区块中包括与不同业务方相关的业务交易。基于此，单一链上的任意一个区块会包含由不同业务方通过不同业务节点所提交的业务交易，所以，在业务网络中的某个业务节点(例如，业务节点A)从核心共识网络的单一链上同步到相应区块时，不仅会同步到与自己相关的交易的账本数据，还会同步到与其他业务方相关交易的账本数据，进而影响了链上交易数据的安全性和隐私性。
发明内容
本申请实施例提供了一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品，能够提升链上交易数据的安全性和隐私性。
本申请实施例提供了一种区块链数据处理方法，方法由局部共识网络中的局部共识节点执行，局部共识网络部署在多层链网络的业务网络中，多层链网络中还部署有独立于所述业务网络的核心共识网络，所述核心共识网络包括核心共识节点；所述方法包括：
将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，所述局部共识交易是指在所述局部共识网络中执行的业务交易，所述主链绑定高度为第一全局共识区块的区块高度，所述第一全局共识区块是在打包所述局部共识交易时从所述核心共 识节点的主链上同步到的，所述主链读数据集合是从第一全局合约状态中所清分到的、且用于执行所述局部共识交易，所述第一全局合约状态为在执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
将所述局部共识区块广播给局部验证节点，所述局部验证节点用于在所同步到的区块高度大于或等于所述主链绑定高度、以及所同步到的读数据集合与所述主链读数据集合一致时，获取所述局部共识交易的交易执行结果所对应的投票共识结果，所述局部验证节点为所述局部共识网络中除所述局部共识节点之外的共识节点；
在基于所述局部验证节点返回的投票共识结果确定达成共识时，将所述局部共识区块上链至所述局部共识网络对应的局部共识子链，并将所述局部共识区块写入局部共识账本数据库。
本申请实施例提供了一种区块链数据处理方法，方法由核心共识网络中的核心共识节点执行；核心共识网络部署在多层链网络中；多层链网络中与所述核心共识网络独立的业务网络部署有局部共识网络，所述局部共识网络包括局部共识节点，所述方法包括：
获取所述局部共识节点发送的主链同步请求，所述主链同步请求携带第三全局共识区块的区块高度；所述第三全局共识区块为所述局部共识节点在同步到第一全局共识区块之前从主链上同步到的全局共识区块；
从所述主链上，将区块高度大于所述第三全局共识区块的区块高度的全局共识区块，确定为未同步给所述局部共识节点的第一全局共识区块；
从所述主链上获取所述第一全局共识区块的第一全局合约状态；所述第一全局合约状态为执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
将所述第一全局共识区块、以及所述第一全局合约状态返回给所述局部共识节点，所述局部共识节点用于基于第一全局共识区块的区块高度和第一全局合约状态，将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，并在基于所述局部共识网络对所述局部共识区块达成共识时，将所述局部共识区块上链至所述局部共识网络中。
本申请实施例提供了一种第一区块链数据处理装置，所述第一区块链数据处理装置运行在局部共识网络中的局部共识节点上，所述局部共识网络部署在多层链网络的业务网络中，所述多层链网络中还部署有独立于所述业务网络的核心共识网络，所述核心共识网络包括核心共识节点，所述第一区块链数据处理装置包括：
打包模块，配置为将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，所述局部共识交易是指在所述局部共识网络中执行的业务交易，所述主链绑定高度为第一全局共识区块的区块高度，所述第一全局共识区块是在打包所述局部共识交易时从所述核心共识节点的主链上同步到的，所述主链读数据集合是从第一全局合约状态中所清分到的、且用于执行所述局部共识交易，所述第一全局合约状态为在执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
共识模块，配置为将所述局部共识区块广播给局部验证节点，所述局部验证节点用于在所同步到的区块高度大于或等于所述主链绑定高度、以及所同步到的读数据集合与所述主链读数据集合一致时，获取所述局部共识交易的交易执行结果所对应的投票共识结果，所述局部验证节点为所述局部共识网络中除所述局部共识节点之外的共识节点；
处理模块，配置为在基于所述局部验证节点返回的投票共识结果确定达成共识时，将所述局部共识区块上链至所述局部共识网络对应的局部共识子链，并将所述局部共识区块写入局部共识账本数据库。
本申请实施例提供了一种第二区块链数据处理装置，所述第二区块链数据处理装置运行在核心共识网络中的核心共识节点上，所述核心共识网络部署在多层链网络中；所述多层链网络中的业务网络部署有局部共识网络，所述局部共识网络是通过独立与所述业务网络的核心共识网络中的核心共识节点所构建的；所述第二区块链数据处理装置包括：
获取模块，配置为获取局部共识节点发送的主链同步请求，所述主链同步请求携带第三全局共识区块的区块高度；所述第三全局共识区块为所述局部共识节点在同步到第一全局共识区块之前从主链上同步到的全局共识区块；
确定模块，配置为从所述主链上，将区块高度大于所述第三全局共识区块的区块高度的全局共识区块，确定为未同步给所述局部共识节点的第一全局共识区块；
所述获取模块，还配置为从所述主链上获取所述第一全局共识区块的第一全局合约状态；所述第一全局合约状态为执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
数据返回模块，配置为将所述第一全局共识区块、以及所述第一全局合约状态返回给所述局部共识节点，所述局部共识节点用于基于第一全局共识区块的区块高度和第一全局合约状态，将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，并在基于所述局部共识网络对所述局部共识区块达成共识时，将所述局部共识区块上链至所述局部共识网络中。
本申请实施例提供了一种用于区块链数据处理的电子设备，电子设备包括存储器和处理器，存储器与处理器相连，存储器用于存储计算机程序，处理器用于调用计算机程序，以使得该电子设备执行本申请实施例提供的应用于局部共识节点中的区块链数据处理方法，或者以使得该电子设备执行本申请实施例提供的应用于核心共识节点中的区块链数据处理方法。
本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序由处理器加载并执行，以使得电子设备执行本申请实施例提供的应用于局部共识节点中的区块链数据处理方法，或者以使得电子设备执行本申请实施例提供的应用于核心共识节点中的区块链数据处理方法。
本申请实施例提供了一种计算机程序产品，计算机程序产品包括计算机程序或计算机可执行指令，该计算机程序或计算机可执行指令被处理器执行时，以实现本申请实施例提供的应用于局部共识节点中的区块链数据处理方法，或者以实现本申请实施例提供的应用于核心共识节点中的区块链数据处理方法。
在本申请实施例中，待上链的局部共识区块可以通过主链绑定高度和主链读数据集合与主链建立关联关系，并在局部共识网络中通过局部共识区块和局部验证节点进行区块共识，以及在确定达成区块共识时，将局部共识区块上链至局部共识子链，并将局部共识区块写入独立于主链子账本数据库的局部共识账本数据库。通过上述过程可以实现在局部共识网络进行局部共识区块的区块共识，并将达到区块共识的局部共识区块写入 局部共识子链中，使得在局部共识网络中所执行交易涉及的交易数据可以存储在相关联的局部共识子链中，以实现各个业务方的业务交易的交易数据的层级化独立管理，实现了不同业务数据的隔离，从而能够提升链上交易数据的安全性和隐私性。
附图说明
为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种多层链网络的架构示意图；
图2是本申请实施例提供的一种基于局部共识网络的区块共识场景示意图；
图3是本申请实施例提供的一种区块链数据处理方法的流程示意图；
图4为本申请实施例提供的一种提议区块的示意图；
图5为本申请实施例提供的一种数据审核的场景示意图；
图6a为本申请实施例提供的一种基于多层链网络的区块链框架示意图；
图6b为本申请实施例提供的另一种基于多层链网络的区块链框架示意图；
图7是本申请实施例提供的一种区块链数据处理方法的流程示意图；
图8是本申请实施例提供的一种区块共识的交互示意图；
图9是本申请实施例提供的一种区块链数据处理方法的流程示意图；
图10是一种区块链网络的分层结构示意图；
图11是本申请实施例提供的一种多层区块链网络的结构示意图；
图12是本申请实施例提供的一种局部共识节点的结构示意图；
图13是本申请是实施例提供的一种多层区块链数据处理过程的流程示意图；
图14是本申请实施例提供的一种多层区块链数据处理方法的流程示意图；
图15是本申请实施例提供的一种账本数据归档过程的流程示意图；
图16是本申请实施例提供的一种账本数据归档过程的流程示意图；
图17是本申请实施例提供的一种账本数据归档过程的流程示意图；
图18是本申请实施例提供的一种多层区块链数据处理方法的流程示意图；
图19是本申请实施例提供的一种多层区块链数据处理方法的流程示意图；
图20是本申请实施例提供的一种区块链数据处理装置的结构示意图；
图21是本申请实施例提供的一种区块链数据处理装置的结构示意图；
图22是本申请实施例提供的一种电子设备的结构示意图；
图23是本申请实施例提供的一种区块链数据处理系统的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他 实施例，都属于本申请保护的范围。
参见图1，图1是本申请实施例提供的一种多层链网络的架构示意图。如图1所示，多层链网络架构可以应用于基于区块链的数据系统(以下简称为区块链系统)，比如，区块链电子票据系统。区块链数据系统所对应的区块链网络可以是多层链网络，该多层链网络包括业务网络和核心共识网络，业务网络处于公网中，核心共识网络处于私网中(比如，私有云)；另外，业务网络中可以部署有一个或多个相互独立的局部共识网络。其中，业务网络中的局部共识网络可以表示为图1所示的局部共识网络100a、100b、......，此处仅示例两个局部共识网络，在此对局部共识网络的数量不做限定，且核心共识网络可以表示为图1所示的核心共识网络200a。
在如图1所示的局部共识网络100a中，部署有多个局部共识节点，示例性示出了局部共识节点10a、10b、10c、10d，这里并不对部署在局部共识网络100a中的局部共识节点的数量进行限定。随着业务需求的变化，局部共识节点的数量可以不断变化。局部共识网络100a中的局部共识节点具备区块共识功能，可以维护与局部共识网络100a关联的局部共识子链。比如，局部共识网络100a中的多个局部共识节点共同维护的区块链为局部共识子链10e。此外，业务网络中还包括与局部共识网络100a具有网络连接关系的一个或多个局部业务节点，示例性示出了局部业务节点30a、30b、30c、30d、30e、30f、30g、....、30n，在此对局部业务节点的数量不做限定。比如，局部共识网络100a中的局部共识子链为业务方A独立管理的区块链，与局部共识网络100a具有网络连接关系的局部业务节点即为业务方A对应的局部业务节点。与局部共识网络100a具有网络连接关系的局部业务节点可以提交待处理的业务交易(如业务交易A)至局部共识网络100a中的局部共识节点，并由局部共识网络100a中的局部共识节点将业务交易A打包至局部共识区块A；最后在局部共识网络100a中针对局部共识区块A达成区块共识后，由局部共识网络100a中的局部共识节点将局部共识区块A上链至局部共识子链10e。
同理，在如图1所示的局部共识网络100b中，部署有多个局部共识节点，示例性示出了局部共识节点11a、11b、11c、11d，这里并不对部署在局部共识网络100b中的局部共识节点的数量进行限定。随着业务需求的变化，局部共识节点的数量可以不断变化。局部共识网络100b中的局部共识节点具备区块共识功能，可以维护与局部共识网络100b关联的局部共识子链。比如，局部共识网络100b中的多个局部共识节点共同维护的区块链为局部共识子链11e。此外，业务网络中还包括与局部共识网络100b具有网络连接关系的一个或多个局部业务节点，示例性示出了局部业务节点31a、31b、31c、31d、31e、31f、31g、....、31n，在此对局部业务节点的数量不做限定。比如，局部共识网络100b中的局部共识子链为业务方B独立管理的区块链，与局部共识网络100b具有网络连接关系的局部业务节点即为业务方B对应的局部业务节点。与局部共识网络100b具有网络连接关系的局部业务节点可以提交待处理的业务交易(如业务交易B)给局部共识网络100b中的局部共识节点，并由局部共识网络100b中的局部共识节点将业务交易B打包至局部共识区块B；最后在局部共识网络100b中针对在局部共识区块B达成区块共识后，由局部共识网络100b中的局部共识节点将局部共识区块B上链至局部共识子链11e。
相应地，在如图1所示的核心共识网络200a中，部署有多个核心共识节点，示例性示出了核心共识节点20a、20b、20c、20d，这里不对部署在核心共识网络200a中的核心共识节点的数量进行限定，随着业务需求的变化，核心共识节点的数量可以不断变化。此外，核心共识网络200a中的多个核心共识节点共同维护的区块链为主链20e。可以理解的是，各个局部共识网络中的局部共识节点可以从主链上同步主链上的全局共识区块。可以理解，局部共识网络是通过核心共识节点创建的。也就是说，业务对象(比如业务方)可以向核心共识节点发送针对局部共识子链的注册交易和配置交易，以激活局部共识网络，并使得可以在局部共识节点上创建局部共识子链中的创世区块以启动局部共识子链，从而完成局部共识网络和局部共识子链的创建。
这里，局部共识节点为核心共识节点对应的全局业务节点。也就是说，局部共识节点不仅可以通过核心共识节点同步主链上的数据，还可以生成业务交易发送给核心共识节点。比如，局部共识节点可以对局部共识网络中的局部共识交易对应的交易执行结果进行交易汇总处理，得到交易汇总信息，并生成携带交易汇总信息的信息上链交易，最后将信息上链交易发送给核心共识节点，由核心共识节点将信息上链交易写入主链。
这里，将核心共识网络中处理的业务交易称为全局共识交易，将局部共识网络中处理的业务交易称为局部共识交易。全局共识交易和局部共识交易可以是不同的。通过本申请实施例所提取的针对局部共识区块的共识机制在局部共识网络中实现局部共识区块的共识和上链，以实现将一些原本只能在核心共识网络中由核心共识节点处理的全局共识交易搬到局部共识网络中由局部共识节点执行；也就是，将这部分搬到局部共识网络中的全局共识交易作为局部共识交易，以及将该局部共识交易涉及的交易数据写入局部共识子链中；如此，不仅可以提升局部共识交易涉及的交易数据安全性，还可以通过局部共识网络为核心共识网络分担业务处理负载，减少主链上的数据混杂度和稳定性。此外，在执行局部共识交易时所需读取的读数据集合可以部分来自于从主链清分到的数据，比如局部共识节点可以从主链清分到全局合约状态数据，该全局合约状态数据可以是指在调用主链上的全局共识执行全局共识交易时所读取到的读数据集合。因此，在执行局部共识交易时可以引用主链上的数据，进行主链上的合约状态数据复用。
在上述区块链数据系统中，核心共识节点用于在对应主链所在的核心共识网络中进行共识，局部共识节点用于在对应局部共识子链所在的局部共识网络中进行共识。核心共识网络或任一个局部共识网络，将业务交易所涉及的交易数据写入对应区块链账本(例如，分布式数据库)的原理相同。以局部共识网络为例，将局部共识网络中的交易数据写入对应区块链账本的过程可以为，客户端发送交易数据至某个局部业务节点，随后该交易数据以接力棒的方式在局部共识网络内的局部业务节点之间传递，直到局部共识网络中的指定的局部共识节点(例如，局部共识网络100a中的局部共识节点10a)收到该交易数据，此时，该局部共识节点再将该交易数据打包进区块，以便于后续可以与其他局部共识节点之间进行区块共识，从而可以在区块共识通过后，将共识通过的局部共识区块写入自己所在局部共识网络(例如，局部共识网络100a)的分布式数据库。
其中，可以理解的是，区块链是一种分布式数据存储、点对点传输、共识机制以及加密算法等计算机技术的新型应用模式，用于对数据按时间顺序进行整理，并加密成账本，使其不可被篡改和伪造，同时可进行数据的验证、存储和更新。区块链本质上是一 个去中心化的数据库，该数据库中的每个节点均存储一条相同的区块链，区块链网络将节点区分为核心节点和轻节点(比如可称为SPV节点)；其中，核心节点用于对区块链全网进行共识，也就是说，核心节点为区块链网络中的共识节点。区块链网络中交易数据被写入账本(例如，本地账本)的过程包括：客户端发送交易数据至轻节点，随后该交易数据以接力棒的方式在区块链网络中的轻节点之间传递，直到共识节点收到该交易数据，共识节点再将该交易数据打包进区块，以便于后续可以与其他共识节点之间进行共识，从而可以在共识通过后，可以通过存储层将携带该交易数据的至少一个区块并行写入分布式数据库，这样可以从根源上突破区块链的区块链结构的限制，进而可以有效地提升数据存储的存储效率。应当理解，核心共识网络中的共识节点为核心共识节点(如图1所示的核心共识网络200a中的核心共识节点20a)。局部共识网络中的共识节点既为局部共识网络中具备区块共识能力的核心节点，也为业务网络中可以从主链上清分交易数据的轻节点(如图1所示的局部共识网络100b中的局部共识节点11a)。
其中，可以理解的是，区块链系统中可以包括智能合约，该智能合约在区块链系统中是一种由区块链各节点(包括共识节点)执行的代码，通过该智能合约可以执行任意逻辑并得到结果。比如，当通过客户端发起一个交易业务请求时，响应于交易业务请求，调用区块链上已经部署的智能合约，随后，区块链上的数据节点或轻节点可以将该交易业务请求发送至共识节点，以调用各个共识节点中运行的智能合约执行该交易业务。应当理解，区块链中可以包括一个或多个智能合约，这些智能合约可以通过合约调用地址、合约标识号(Identity Document，ID)或合约名称来进行区分，而客户端发起的交易业务请求中，也可以携带智能合约的合约调用地址或者合约标识号或合约名称，以此指定需要运行的智能合约。而若客户端所指定的智能合约为需要读取数据的合约(即业务合约)，则各个共识节点会优先访问在存储层中的本地缓存来进行数据的读取，最后各个共识节点会互相验证各交易执行结果是否一致(也就是进行共识)，若一致则可以将交易执行结果存入各自的本地缓存和本地存储中，并可以将上述交易业务的交易执行结果返回至客户端。这里的本地缓存为在存储层中创建的系统内存，这里的本地存储为在存储层中所创建的用于进行数据存储的硬盘空间。这样，当某个共识节点出现宕机或者系统故障时，并不会因为系统内存中的数据消失而造成无法进行数据读取的现象，即该共识节点还可以通过在该存储层中的本地存储来进行数据的读取。
应当理解，在上述区块链数据系统中，任意一个共识网络(例如，局部共识网络100a或核心共识网络200a等)中的任意两个区块链节点之间可以形成点对点(Peer To Peer，P2P)网络，该点对点网络可以采用P2P协议，其中，该P2P协议是一个运行在传输控制协议(Transmission Control Protocol，TCP)协议之上的应用层协议。在分布式系统中，任何设备如服务器、终端等都可以加入而成为区块链节点，其中，每个区块链节点均可以包括硬件层、中间层、操作系统层和应用层。
可以理解的是，本申请实施例可以为接入区块链网络的任意一类业务方(例如，任一个人用户、任意一个企业、任意一个机构等实体对象)绑定一个区块链节点，以将这些区块链节点所构成的区块链网络统称为联盟链网络。所以，如图1所示的局部共识节点10a、10b......等可以分别与待接入该联盟链网络中的相应业务方(即相应业务场景下的实体对象)之间存在一一对应关系。这里的业务场景可以包含电子票据场景、社交场 景、赊购场景、信贷场景等。此时，相应业务场景下的目标业务具体可以包含电子票据业务、社交业务、赊购业务、信贷业务等，这里将不对相应业务场景下的具体业务进行一一列举。因此，本申请实施例可以应用于任意可部署区块链网络的业务场景中，上述区块链数据系统也可以与具体应用的业务场景适配。
可以理解，在不同应用场景下，局部共识网络上执行的业务交易以及发起业务交易的业务方可以是不同的。也就是说，局部共识网络可以是基于不同类型的业务方所创建的。例如，可以按照区域划分业务方，不同区域的业务方接入各自区域对应的局部共识网络。比如，主链可以用于存储与全国票据业务相关的交易数据，处于地区A的业务方可以接入地区A对应的局部共识网络A，以在局部共识网络A中执行与地区A相关的票据业务交易(如在地区A中进行与地区A相关的票据抽奖业务)，此时局部共识网络A中的局部共识子链可以用于存储与地区A票据业务相关的交易数据；处于地区B的业务方可以接入地区B对应的局部共识网络，以在局部共识网络中执行与地区B相关的票据业务交易(如在地区B中进行与地区B相关的票据抽奖业务)，此时局部共识网络B中的局部共识子链可以用于存储与地区B票据业务相关的交易数据。也就是说，通过本申请实施例可以为各种业务方搭建独立于主链、专属为各种业务方服务的局部共识子链。可以在各种业务方各自对应的局部共识网络中进行与各个业务方相关的业务交易，并将与各个业务方相关的业务交易所涉及的交易数据打包上链至各个业务方关联的局部共识子链中，可以实现交易数据的安全性、隐私性，以及数据隔离。
为便于理解，基于图1，参见图2，图2是本申请实施例提供的一种基于局部共识网络的区块共识场景示意图。在此场景下，提出了一种针对局部共识区块的共识机制，通过该针对局部共识区块的共识机制，可以实现在局部共识网络中对区别于主链上全局共识区块的局部共识区块的区块共识，且在达成区块共识后进行区块的上链，使得局部共识网络中具有区别于主链的局部共识子链，并且，该局部共识子链上的局部共识区块与主链存在关联关系，以便于主链对局部共识子链的管理。本申请实施例所提出的局部共识节点可以是图1中的任意一个局部共识节点(比如局部共识网络100a中的局部共识节点10a，或者局部共识节点10b，或者局部共识节点10c)。其中，局部共识区块的区块共识和上链过程可以是：局部共识节点从交易池中获取缓存的局部共识交易，以将获取到的局部共识交易打包至提议区块中，此时可以从局部共识节点的主链子账本数据库中获取主链绑定高度和主链读数据集合，并将主链绑定高度和主链读数据集合、以及局部共识交易一并打包至提议区块，此时可以将包含主链绑定高度、主链读数据集合以及局部共识交易的提议区块作为待共识的局部共识区块，在对局部共识区块进行区块共识时，将局部共识区块广播给局部共识网络中的局部验证节点(也就是局部共识网络中除局部共识节点之外的共识节点)，局部验证节点可以对局部共识区块中的主链绑定高度和主链读数据集合进行数据审核，并在数据审核成功时对执行局部共识交易所得到的交易执行结果进行投票共识，得到投票共识结果，局部共识节点接收局部验证节点返回的投票共识结果，在基于投票共识结果确定达成区块共识时，表示完成对局部共识区块的共识过程，可以将局部共识区块上链至所维护的局部共识子链中，且将局部共识区块写入独立于主链子账本数据库的局部共识账本数据库中。
应当理解，主链读数据集合是指在执行局部共识交易时需要从主链上读取的数据， 比如全局共识业务合约的全局合约状态。通过主链绑定高度和主链读数据集合可以使得局部共识区块与主链具有关联关系，从而可以在执行局部共识区块中的局部共识交易时引用主链读数据集合，并且通过主链绑定高度使得各个共识节点(也就是局部共识节点和局部验证节点)在对主链读数据集合进行数据审核时，对主链读数据集合的一致性进行验证，以确保基于主链读数据集合所执行的局部共识交易的交易执行结果一致。
此外，局部共识节点在将待共识的局部共识区块广播给局部验证节点后，局部共识节点和局部验证节点均对该局部共识区块进行相同步骤的区块共识。以一个共识节点为例，区块共识的过程可以是：对局部共识区块中的主链绑定高度和主链读数据集合进行数据审核，在数据审核成功时执行局部共识区块中的局部共识交易得到交易执行结果，并与其他共识节点相互验证各个共识节点得到的交易执行结果(也就是区块共识结果)，当确定存在一定数量个共识节点得到的交易执行结果与自身得到的交易执行结果一致时，生成指示交易结果一致的投票共识结果(也就是进行投票共识)，当接收到其他共识节点返回的投票共识结果，且确定当前具有的投票共识结果中存在一定数量个投票共识结果指示交易结果一致时，则确定达成区块共识，并将该局部共识区块上链至所维护的局部共识子链中。也就是说，在局部共识节点将局部共识区块广播给局部验证节点，且局部共识节点和局部验证节点均需进行区块共识时，执行的区块共识操作相同。比如，局部共识节点10a将执行局部共识交易得到的交易执行结果作为第一交易结果，并获取局部共识节点10b至10d得到的交易执行结果，将局部共识节点10b至10d得到的交易执行结果作为第二交易结果，对比第一交易结果和第二交易结果，若确定存在一定数量的第二交易结果与第一交易交易结果相同，则表示交易执行结果一致，此时，生成指示投票赞同的投票共识结果。又如，局部共识节点10a获取局部共识节点10b至10d得到的投票共识结果，若局部共识节点10a至10d所得到的投票共识结果中指示投票赞同的结果数量达到一定数量，则表示达成区块共识。
可以理解，各个局部共识节点在进行区块共识时，不仅会对主链绑定高度和主链读数据集合进行数据审核，还会对交易执行结果进行投票共识，并根据自身得到的和接收到的投票共识结果确定是否达成区块共识。例如，如图1中的局部共识网络100a，当局部共识节点10a将局部共识区块广播至局部共识节点10b、10c和10d后，对于局部共识节点10a而言，局部共识节点10b、10c和10d是局部验证节点；而对于局部共识节点10b而言，局部共识节点10a、10c和10d是局部验证节点；而对于局部共识节点10c而言，局部共识节点10b、10a和10d是局部验证节点；而对于局部共识节点10d而言，局部共识节点10b、10c和10a是局部验证节点；局部共识节点10a-10d均会对局部共识节点中的主链绑定高度和主链读数据集合进行数据审核，并在数据审核成功时对执行局部共识交易得到的交易执行结果(该交易执行结果也就是指对局部共识区块进行区块共识所得到的区块共识结果)进行投票共识得到投票共识结果，并将投票共识结果分别发送给剩余局部共识节点(比如局部共识节点10a将投票共识结果发送给局部共识节点10b至10d)，局部共识节点10a至10d均会基于自身的投票共识结果和接收到的投票共识结果确定是否达成区块共识，并在确定达成区块共识时对局部共识区块进行上链，实现局部共识子链的搭建。
其中，局部共识节点(如局部共识节点10a)中可以包括：局部子链共识RPC(Re  mote Procedure Call，远程过程调用)组件2-1、局部子链共识组件2-2、局部链交易执行组件2-3、局部共识账本数据库2-4、主链共识RPC组件2-5、主链转发上链组件2-6、主链清分同步组件2-7、主链合约状态读取组件2-8、主链子账本数据库2-9。可以理解，局部共识节点包括两个部分(部分1对应图2所示的2-1至2-4、部分2对应图2所示的2-5至2-9)，部分1用于接收局部共识交易，将局部共识交易打包成局部共识区块，对局部共识区块进行区块共识和上链；部分2用于同步主链数据，并从所同步的主链数据中清分到与自身相关的主链数据(比如在执行局部共识交易时所需从主链引用的全局合约状态)，以及还可以生成需要主链执行的业务交易并转发上链。局部共识账本数据库2-4和主链子账本数据库2-9相互独立。
其中，局部共识节点10a可以通过主链清分同步组件2-7从核心共识网络200a中的核心共识节点(比如，核心共识节点20a、核心共识节点20b、核心共识节点20c和核心共识节点20d中的任一个)上同步主链上的全局共识区块、以及与全局共识区块关联的全局合约状态，并将从同步到的主链数据写入主链子账本数据库2-9。比如局部共识节点10a可以通过核心共识网络200a中的核心共识节点20c对主链进行同步；局部共识节点10a在生成待上链至主链的业务交易时，可以触发主链共识RPC组件2-5调用主链转发上链组件2-6，以将待上链至主链的业务交易转发至核心共识节点20c，由核心共识节点20c将从主链转发上链组件2-6接收到的业务交易写入主链，比如可以是由主链共识RPC组件2-5对待上链至主链的业务交易进行交易校验，并通过主链共识RPC组件2-5调用主链转发上链组件2-6将校验成功的业务交易转发至核心共识节点20c。
其中，局部共识节点10a当接收到局部共识交易时，可以调用局部子链共识RPC组件2-1对局部共识交易进行交易校验并放入交易池中，以及通过局部子链共识RPC组件2-1调用局部子链共识组件2-2从交易池中获取所缓存的局部共识交易，由局部子链共识组件2-2将获取到的局部共识交易打包至提议区块，此时可以通过局部子链共识组件2-2调用主链合约状态数读取组件2-8，以从主链子账本数据库2-9获取主链绑定高度和主链读数据集合，并由局部子链共识组件2-2将获取到的主链绑定高度和主链读数据集合一并打包至提议区块，此时的提议区块为待共识的局部共识区块。该局部共识区块通过主链绑定高度与主链进行了状态绑定，并且通过主链读数据集合对主链进行了数据引用。局部子链共识组件2-2在对局部共识区块进行区块共识时，可以将局部共识区块广播给局部共识网络中的局部验证节点(如局部共识节点10b至10d)，以使得局部共识节点10a和局部共识节点10b至10d对局部共识区块进行投票共识。
其中，局部共识节点10a可以通过局部子链共识组件2-2对局部共识区块中的主链绑定高度和主链读数据集合进行数据审核，并在数据审核成功时对局部共识区块进行区块共识以得到区块共识结果，并基于区块共识结果进行投票共识得到投票共识结果，此时局部共识节点10a可以接收局部共识节点10b至10d所返回的投票共识结果，在基于自身的投票共识结果和局部共识节点10b至10d所返回的投票共识结果确定达成区块共识时，将局部共识区块上链至局部共识网络对应的局部共识子链，且将局部共识区块写入主链子账本数据库2-9，比如可以是由局部子链共识组件2-2将局部共识区块写入主链子账本数据库2-9，或者通过局部链交易执行组件2-3将局部共识区块写入主链子账本数据库2-9。可以理解，若数据审核未成功，则结束执行对局部共识区块进行区块共 识的后续流程。
其中，局部共识节点10a对局部共识区块进行区块共识以得到区块共识结果包括：通过局部子链共识组件2-2调用局部链交易执行组件2-3执行局部共识区块中的局部共识交易得到交易执行结果，并将交易执行结果作为区块共识结果。此时，局部链交易执行组件2-3在执行局部共识交易时，则可以是调用局部共识业务合约读取局部共识区块中的主链读数据集合，通过读取到的主链读数据集合执行局部共识交易，以实现针对主链的数据引用。局部共识节点10a可以通过局部子链共识组件2-2相互验证与其他局部共识节点区块共识结果是否一致(比如是否存在一定数量的区块共识结果与局部共识节点10a所得到的区块共识结果相同，若存在则表示达成一致)，如果达成一致则生成指示投票赞同的投票共识结果，如果未达成一致则生成指示投票反对的投票共识结果。
应当理解，对于局部共识节点10b至10d所进行区块共识的过程与局部共识节点10a相同，本申请实施例在此不再重复描述。
本申请实施例所涉及的核心共识节点和局部共识节点可以是电子设备，电子设备可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。
需要说明的是，本申请实施例中的核心共识节点或局部共识节点在跨链获取业务对象(例如，上述个人对象或者企业对象)的业务数据(比如多层链网络应用于电子票据场景中时，业务数据可以是指业务对象的电子票据)时，可以显示提示界面或者弹窗，该提示界面或者弹窗用于提示业务对象当前正在搜集票据资产等数据，并在获取到业务对象对该提示界面或者弹窗发出确认操作后，开始执行数据获取的相关的步骤，否则结束。
此外，可以理解的是，在本申请实施例中，可能涉及到用户等业务对象的业务数据(例如，在执行局部共识区块中的局部共识交易时，根据局部共识交易的不同可能会涉及需要获取开票信息、征信信息、退税信息，企业的进出亏、企业资质等信息)，当本申请实施例运用到具体产品或技术中时，需要获得用户等业务对象的许可或同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
下面说明在局部共识网络中对局部共识区块进行区块共识的过程。
参见图3，图3是本申请实施例提供的一种区块链数据处理方法的流程示意图，如图3所示，方法可以由上述提及的局部共识网络中的局部共识节点来执行，比如，该局部共识节点可以为图1所示的局部共识网络100a中任意一个局部共识节点。方法包括以下步骤S301至步骤S303，下面对各步骤分别进行说明。
S301，将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，局部共识交易是指在局部共识网络中执行的业务交易，主链绑定高度为第一全局共识区块的区块高度，第一全局共识区块是在打包局部共识交易时从核心共识节点的主链上同步到的，主链读数据集合是从第一全局合约状态中所清分到的、且用于执行局部共识交易，第一全局合约状态为在执行第一全局共识区块中的全局共识交易时所读取到的读数据集合。
其中，局部共识节点可以从交易池中获取缓存的局部共识交易，并将局部共识交易打包至提议区块中。提议区块包括区块头、所打包的交易列表等区块数据。在将局部共识交易打包至提议区块时，可以从主链子账本数据库中获取从主链上同步到的全局共识区块的区块高度，并将此时同步到的区块高度作为主链绑定高度。局部共识节点还可以从同步到全局共识区块中获取与当前打包的局部共识交易所关联的主链读数据集合，该主链读数据集合是指在执行局部共识交易需要从主链读取的数据，如全局共识业务合约所关联的合约状态。局部共识节点可以将主链绑定高度和主链读数据集合、以及局部共识交易一并打包至提议区块，以得到与主链具有关联关系的提议区块。例如，如图4所示，图4为本申请实施例提供的一种提议区块的示意图；其中，提议区块4-1可以包括区块头数据4-11(如区块高度、提案者、随机数、时间戳等数据)、局部共识交易的交易列表4-12(如包括交易1、交易2、....)、主链绑定高度4-13和主链读数据集合4-14；主链读数据集合4-14表示在执行交易列表4-12中的局部共识交易时所需要从主链读取的全局合约状态，主链读数据集合4-14包括一个或多个键值对(比如表示为[key1：value1；key2：value2；....])，“keyx：valuex”表示一个键值对，“keyx”keyx表示所读取的键值数据，“valuex”表示对应读取到的值数据；比如，当读取的第一全局合约状态是电子票据开具合约中的电子票据模板时，则“keyx”表示电子票据模板，“valuex”表示电子票据模板对应的具体数据。
为了便于理解，可以将在局部共识交易进行打包时所最新同步到的全局共识区块称为第一全局共识区块；也就是说，主链绑定高度为在打包局部共识交易时从核心共识节点所维护的主链上所同步到的第一全局共识区块的区块高度。例如，主链上的全局共识区块的当前区块高度为100，局部共识节点在打包局部共识交易时从主链上最新同步到的全局共识区块的区块高度为80，则主链绑定高度为80，该最新同步到的全局共识区块即为第一全局共识区块。
其中，在通过核心共识节点从主链上获取到最大全局区块高度对应的全局共识区块时，将最大全局区块高度对应的全局共识区块作为第一全局共识区块，且将最大全局区块高度作为主链绑定高度。也就是说，局部共识节点会从主链上同步最新上链至主链的全局共识区块，并将该最新上链至主链的全局共识区块作为第一全局共识区块，且将最新上链至主链的全局共识区块的区块高度作为主链绑定高度。
需要说明的是，主链子账本数据库用于存储从主链所同步到的第一全局共识区块和第一全局共识区块所关联的第一全局合约状态，第一全局合约状态为在核心共识网络中调用主链上的全局共识业务合约执行第一全局共识区块中的全局共识交易时所读取到的读数据集合。主链读数据集合为从第一全局合约状态数据中所清分到的用于执行局部共识交易所需读取的读数据集合。局部共识节点可以在打包局部共识交易时确定该局部共识交易待使用到主链上的数据(也就是键值数据)，并从主链子账本数据库中读取到待使用的数据(也就是根据键值数据从主链子账本数据库中读取最新的值数据)，从而得到主链读数据集合，完成对主链的数据引用。比如，业务方在基于在主链上开具的电子票据进行抽奖，且抽奖业务交易在局部共识网络中进行，抽奖规则可以作为全局合约状态在全局共识业务合约中声明，局部共识节点从主链上同步数据时会把这个全局合约状态也同步并放入主链子账本数据库，在打包由业务方发起的抽奖业务交易(称为局部 共识交易)时，若确定从主链上读取抽奖规则对应的全局合约状态，则从主链子账本数据库获取到抽奖规则，以构建主链读数据集合并打包至局部共识区块中，后续局部共识节点在局部共识区块执行该抽奖业务交易时可以从主链读数据集合读取到抽奖规则，并基于从主链上读取到的抽奖规则和相关局部共识业务合约执行该抽奖业务交易，此时抽奖规则表示从主链上引用的数据。可以理解，根据局部共识交易的不同，在不同场景下从主链上引用的全局合约状态不同，根据具体区块链场景确定，在此仅为示例，并不做限定。
可以理解的是，主链绑定高度用于将当前进行区块共识的局部共识区块与主链进行状态绑定(又可称为合约状态数据绑定)。也就是说，局部共识区块会在打包局部共识交易时确定同步到的全局共识区块的区块高度，并从主链所同步到的数据中获取最新的主链读数据集合。比如，主链绑定高度为100，则表示在打包局部共识交易时同步主链的全局共识区块为区块高度为100的全局共识区块，并在同步到的区块高度为100的全局共识区块及之前的全局共识区块(即区块高度0-100的全局共识区块)所关联的全局合约状态数据中，清分用于执行局部共识交易所需读取的最新读数据集合，以作为主链读数据集合。
在一些实施例中，局部共识网络是由核心共识网络中的核心共识节点所创建的，在创建局部共识网络时局部共识节点会创建局部共识子链的创世区块以启动局部共识子链；该过程包括：从主链上同步写入有注册交易的目标共识区块，该注册交易是指向核心共识节点申请注册局部共识子链的业务交易，目标共识区块中包括由注册交易对应的配置交易，该配置交易携带有局部共识子链上的创世区块的配置信息，从目标共识区块中获取配置信息，在对配置信息进行信息验证成功后，在局部共识网络中创建创世区块，并基于创世区块启动局部共识子链。可以理解，在通过核心共识网络创建创世区块并启动局部共识子链时，表示局部共识网络被创建及激活。
可以理解，注册交易由业务方发起，注册交易中可以携带创世区块的哈希数据等信息，核心共识节点执行注册交易得到局部共识子链标识，并将注册交易以及局部共识子链标识写入主链，比如写入主链后该注册交易所在的区块高度为X。在注册成功后业务方可以发起配置交易，该配置交易中携带了局部共识子链中的创世区块的配置信息，核心共识节点可以将配置交易写入主链，此时可能是写入注册交易所在的全局共识区块时，也可能是写入注册交易所在的全局共识区块之后的全局共识区块，即配置交易所在的区块高度可能是大于或等于X的。因此，局部共识节点首先需要至少从主链上同步区块高度X的全局共识区块(即目标共识区块)，并从同步到的全局共识区块查找创世区块的配置信息，若区块高度X的全局共识区块未查找到，则继续同步后续全局共识区块，直至查找到包含配置信息的全局共识区块。局部共识节点可以通过子链启动服务指定局部共识子链的标识以及配置创世区块的配置信息，并对从主链上获取到的配置信息以及在局部共识节点所配置的配置信息进行对比(也就是对配置信息进行信息验证成功)，当对比结果指示一致时(也就是信息验证成功)，创建创世区块，以启动局部共识子链，此时，局部共识网络对应启动。
S302，将局部共识区块广播给局部验证节点，局部验证节点用于在所同步到的区块高度大于或等于主链绑定高度、以及所同步到的读数据集合与主链读数据集合一致时， 获取局部共识交易的交易执行结果所对应的投票共识结果，局部验证节点为局部共识网络中除局部共识节点之外的共识节点。
可以理解的是，在对局部共识区块进行区块共识时，首先需要将局部共识区块广播给局部共识网络中的局部验证节点。该局部验证节点为局部共识网络中除局部共识节点以外的共识节点。也就是说，局部共识网络可以包括多个局部共识节点，当任一个局部共识节点打包局部共识交易生成局部共识区块，并对该局部共识区块进行区块共识时，局部共识网络中的其余局部共识节点可以作为当前局部共识节点的局部验证节点，当任一局部验证节点接收到局部共识区块时，需要对该局部共识区块进行区块共识，此时对于该任一局部验证节点而言，该任一局部验证节点所对应的其余局部共识节点同样为该任一局部验证节点的局部验证节点。显然，局部共识网络中的各个局部共识节点在对一个局部共识区块进行区块共识时，所执行的区块共识过程相同。当各个局部共识区块确定该局部共识区块达到区块共识时，由各个局部共识节点将该局部共识区块上链至局部共识子链。
其中，当将局部共识区块广播给局部共识网络中的局部验证节点时，局部验证节点对局部共识区块的区块共识过程可以是：对局部共识区块中主链绑定高度和主链读数据集合进行数据审核，并对局部共识区块中的区块头和交易列表进行合法性校验(比如，对交易列表中的局部共识交易进行格式校验、有效性校验等)，若数据审核成功且合法性校验成功，则对执行局部共识交易所得到的交易执行结果进行投票共识，得到投票共识结果，该投票共识结果会发送给其余局部共识节点；若数据审核不成功或合法性交易不成功，则结束区块共识流程。
每个局部验证节点对主链绑定高度和主链读数据集合进行数据审核的过程和原理相同，包括：从主链子账本数据库中获取在进行区块共识时从主链上最新同步到的全局共识区块的区块高度，并将最新同步到的全局共识区块的区块高度(称为第二全局共识区块的区块高度)，根据第二全局共识区块的区块高度对主链绑定高度和主链读数据集合进行数据审核。
可以理解，在对局部共识交易进行打包至区块共识的期间，局部共识节点可以从主链上同步全局共识区块，相应地，局部验证节点也会不断从主链上同步全局共识区块。同步全局共识区块的过程可以是：调用主链清分同步组件生成主链清分同步请求，该主链清分同步请求携带第一全局共识区块的区块高度，将主链清分同步请求发送给核心共识节点，接收核心共识节点返回的待同步全局区块，此时可以将待同步全局区块作为第二全局共识区块。其中，主链清分同步请求用于指示核心共识节点基于全局清分同步规则和第一全局共识区块的区块高度从主链上确定未同步给局部共识节点的全局共识区块，并从未同步给局部共识节点的全局共识区块选取待同步全局区块。当局部共识节点接收到待同步全局区块时，可以判断该待同步全局区块与第一全局共识区块是否是相同全局共识区块，也就是判断待同步全局区块的区块高度与第一全局共识区块的区块高度。
其中，根据第二全局共识区块的区块高度对主链绑定高度和主链读数据集合进行数据审核可以是，将第二全局共识区块的区块高度作为待确认区块高度，若主链绑定高度小于或等于待确认区块高度，则从主链子账本数据库中查找与第一全局共识区块相关联的读数据集合，并将该读数据集合作为待确认读数据集合，若待确认读数据集合与主链 读数据集合保持一致，则表示数据审核成功。也就是说，局部验证节点会基于主链读数据集合从本地的主链子账本数据库中获取与第一全局共识区块相关联的读数据集合，该与第一全局共识区块相关联的读数据集合包括多个键值对所包含的键值数据，与主链读数据集合包括的多个键值对所包含的键值数据是相同的，局部验证节点从本地查找该键值数据所对应的值数据以构建与第一全局共识区块相关联的读数据集合，通过对主链读数据集合和本地所存储的读数据集合进行对比可以确保所引用的主链数据的一致性。比如，主链读数据集合包括表示抽奖规则的键值对，局部验证节点可以从本地的主链子账本数据库中查找该抽奖规则，该查找的抽奖规则即为与第一全局共识区块相关联的读数据集合中的键值对(也即待确认读数据集合中的键值对)，可以对主链读数据集合中的抽奖规则和待确认读数据集合中的抽奖规则进行对比，以确定局部共识区块中的主链读数据集合中的键值对是否与本地同步到的键值对一致。
需要说明的是，主链绑定高度小于或等于待确认区块高度，表示局部验证节点在区块共识时所同步到的全局共识区块等于或多于局部共识节点在打包局部共识交易时所同步到的全局共识区块。也就是说，局部验证节点本地存储有局部共识节点在打包局部共识交易时所同步到的全局合约状态，因此局部验证节点可以通过主链读数据集合进行数据审核。若主链绑定高度大于待确认区块高度，表示局部验证节点在区块共识时所同步到的全局共识区块少于局部共识节点在打包局部共识交易时所同步到的全局共识区块。也就是说，局部验证节点本地未存储有局部共识节点在打包局部共识交易时所同步到的全部全局合约状态，因此局部验证节点无法对主链读数据集合进行一致性验证，也就不能参与局部共识区块的投票共识。此外，主链绑定高度小于或等于待确认区块高度，表示局部验证节点已同步至主链绑定高度对应的全局共识区块(也就是第一全局共识区块)，因此从同步到的区块高度为主链绑定高度的全局共识区块及之前的全局共识区块(即区块高度0至主链绑定高度的全局共识区块)所关联的全局合约状态中，能够查找得到待确认读取数据集合。
局部验证节点在进行投票共识时，包括：对局部共识区块进行区块共识，得到区块共识结果，基于区块共识结果进行投票共识，得到投票共识结果。其中，对局部共识区块进行区块共识得到区块共识结果，可以是调用局部共识业务合约执行局部共识区块中的局部共识交易，将执行局部共识交易所得到的交易执行结果作为对局部共识区块进行区块共识时的区块共识结果。基于区块共识结果进行投票共识可以是，将区块共识结果在共识节点间比较，若确定达到一定数量的其他共识节点(比如局部共识网络中的51％个局部共识节点)所确定的区块共识结果与自己得到的区块共识结果是相同的(也就是区块共识结果达成一致)，则可以生成指示投票赞同的投票共识结果，此表示区块共识结果达成共识，即局部验证节点赞同将局部共识区块上链至局部共识子链。一个局部验证节点的投票共识结果会发送给其他局部验证节点和局部共识节点，自己也会接收到其他局部验证节点和局部共识节点发送的投票共识结果。相应地，打包生成局部共识区块的局部共识节点，也会执行上述的投票共识过程，并将得到的投票共识结果发送给局部验证节点。
可以理解，局部共识网络中的每个局部共识节点在对局部共识区块进行区块共识时，均会执行局部共识区块中的局部共识交易以得到区块共识结果，并在共识节点(包括局 部共识节点和局部验证节点)间相互验证区块共识结果是否一致，以生成相应地的投票共识结果。每个局部共识节点都可以接收到其余局部共识节点所生成的投票共识结果。也就是说，各个局部共识节点在进行区块共识时，均会执行对主链绑定高度和主链读数据集合进行数据审核的步骤，且在数据审核时，均会判断已同步到的全局共识区块的区块高度是否大于或等于主链绑定高度，且从主链绑定高度对应的全局共识区块及之前的全局共识区块所关联的全局合约状态中查找与第一全局共识区块所关联的读数据集合，以作为待确认数据集合，并基于待确认数据集合对主链读数据集合进行一致性验证。
例如图5，图5为本申请实施例提供的一种数据审核的场景示意图；如图5所示，比如此时局部共识节点50a在时间点A打包局部共识交易，获取在时间点A所同步到的全局共识区块的区块高度(也就是第一全局共识区块的区块高度)，比如此时同步到的区块高度的高度值为100，则将该区块高度100作为主链绑定高度，并在主链子账本数据库中从全局共识区块0至100所关联的全局合约状态中查找主链读数据集合(比如此处的主链读数据集合中的键值对可以表示为：[k1:v1；k2:v2])，从而将得到的局部共识区块广播给局部共识节点50b、50c和50d。
在一个或者多个可实现方式中，当局部共识节点50b的审核时间戳为时间点B时，也就是在时间点B对局部共识区块进行数据审核，可以获取到在时间点B时自己本地所维护的主链同步高度，该局部共识节点50b的本地所维护的主链同步高度，是指该局部共识节点50b当前(即时间点B这一审核时间戳时)所维护的从主链所同步到的全局共识区块的区块高度(也就是第二全局共识区块的区块高度)；比如，此时自己本地当前所维护的从主链所同步到的区块高度的高度值为99，则可以将高度值为99的区块高度作为待确认区块高度，进而可以在确定待确认区块高度小于主链绑定高度时，确认自己本地所维护的主链同步高度是落后于主链同步高度的；此时，局部共识节点50b自身是没有办法进行区块投票的(即该局部共识节点50b此时并不具备用于执行局部共识交易所需要的交易读数据集合)，进而确定出局部共识区块的审核失败信息(称为数据审核结果)，该审核失败信息用于表征数据审核不成功。
相应地，当局部共识节点50c的审核时间戳为时间点B时，也就是在时间点B时对局部共识区块进行数据审核，可以获取到在时间点B时自己本地所维护的主链同步高度，该局部共识节点50c的本地所维护的主链同步高度，是指该局部共识节点50c当前(即时间点B这一审核时间戳时)所维护的从主链所同步到的全局共识区块的区块高度(也就是第二全局共识区块的区块高度)；比如，此时自己本地当前所维护的从主链所同步到的区块高度为100，则可以将高度值为100的区块高度作为待确认区块高度，进而可以在确定待确认区块高度等于主链绑定高度；此时，该局部共识节点50c能够进行区块投票的(即局部共识节点50c此时具备用于执行局部共识区块中的局部共识交易所需要的交易读数据集合)；因此可以在本地的主链子账本数据库中，从高度值0至100的区块高度对应的全局共识区块所关联的全局合约状态中查找待确认读数据集合(也就是与第一全局共识区块所关联的读数据集合)，对待确认数据集合和主链读数据集合进行对比，并将对比结果作为数据审核结果；比如，此处的待确认读数据集合中的键值对可以表示为：[k1:v1′；k2:v2′]，v1′和v2′表示局部共识节点50c从本地查找到的值数据，当v1和v1′相同、且v2和v2′相同时，表示待确认读数据集合和主链读数据集合保 持一致，从而生成局部共识区块的审核成功信息(即为数据审核结果)，该审核成功信息用于表征数据审核成功；另外，当v1和v1′不同或v2和v2′不同时，表示待确认读数据集合和主链读数据集合不一致，从而生成对局部共识区块的审核失败信息(即为数据审核结果)，该审核失败信息用于表征数据审核不成功。
相应地，局部共识节点50d在时间点B时对局部共识区块进行数据审核的过程，与局部共识节点50c在时间点B时对局部共识区块进行数据审核的过程类似，本申请实施例在此不再重复描述。另外，局部共识节点50d的待确认读数据集合中的键值对可以表示为：[k1:v1″；k2:v2″])，v1″和v2″表示局部共识节点50d从本地查找到的值数据，当v1和v1″相同、且v2和v2″相同时，表示待确认读数据集合和主链读数据集合一致，从而生审核成功信息，表征数据审核成功；当v1和v1″不同或v2和v2″不同时，表示待确认读数据集合和主链读数据集合不一致，从而生成审核失败信息，表征数据审核不成功。此外，局部共识节点50b至50d所对应的时间点B可以是不同的。
S303，在基于局部验证节点返回的投票共识结果确定达成共识时，将局部共识区块上链至局部共识网络对应的局部共识子链，并将局部共识区块写入局部共识账本数据库。
其中，局部共识节点可以接收局部验证节点返回的投票共识结果，并基于接收到的投票共识结果和自己确定的投票共识结果(即确定自己得到的区块共识结果与局部验证节点所得到的区块共识结果是否一致)确定是否达成区块共识(又称为达成共识)。若确定指示投票赞同的投票共识结果的数量超过一定数量(比如局部共识网络中局部共识节点的数量的51％)，则表示达成区块共识。此时局部共识节点可以将局部共识区块写入所维护的局部共识子链以及写入本地的局部共识账本数据库中。相应地，局部验证节点同样会接收到这些投票共识结果，并基于这些投票共识结果确定达成区块共识，以将局部共识节点上链各自维护的局部共识子链以及写入各自的局部共识账本数据库中。也就是说，局部共识子链和局部共识账本数据库中完整存储了局部共识区块对于主链的数据引用。
可以理解的是，通过上述过程可以实现在局部共识网络中进行局部共识区块的区块共识，并将达成区块共识的局部共识区块上链至独立于主链的局部共识子链，且局部共识区块与主链存在关联关系，局部共识区块不仅可以基于该关联关系引用主链上的数据，还可以基于该关联关系验证所引用数据的一致性，确保业务交易可以安全准确的执行。通过该区块共识方式可以方便搭建和使用局部共识子链，从而可以构建多层链网络，该多层链网络包括核心共识网络和部署有局部共识网络的业务网络。多层链网络实现了区块链网络的层级划分，局部共识网络中的局部共识节点可以获取核心共识网络中的主链上的数据，还可以用于在本地进行局部共识，使得局部共识网络的各局部共识节点来处理该局部共识网络所在区域的相关业务交易，形成业务交易的多级分层，比如与全国相关的业务交易可以在核心共识网络中由核心共识节点执行，与某个地区相关的业务交易可以在该地区关联的局部共识网络中由局部共识节点执行。同时还可以通过局部共识网络实现业务交易数据的数据隔离，比如与地区A相关的业务交易数据上链至地区A关联的局部共识网络中的局部共识子链，与地区B相关的业务交易数据上链至地区B关联的局部共识网络中的局部共识子链，以保证重要交易数据的安全。此外，局部共识网络还可以为主链分担业务处理压力，确保主链上的业务处理的稳定性。例如，以区块链 电子票据系统为例，业务交易的多级分层可以是：在核心共识网络中运行主链，核心共识网络中的核心共识节点可以用于执行与全国相关的票据业务交易，各个一级地区票据机构(比如省级的税务机构)可以创建各自的局部共识网络，并在各自的局部共识网络中搭建各自的局部共识子链。
可以理解，由于局部共识网络部署在业务网络中，因此业务网络中可以包括多类SPV节点，比如第一类SPV节点、第二类SPV节点。其中，第一类SPV节点用于通过具有网络连接关系的共识节点从该共识节点所维护的区块链上同步共识区块，并搭建属于自己的区块链。比如，局部共识节点可以通过具有网络连接关系的核心共识节点从核心共识节点所维护的主链上同步全局共识区块；也就是说，局部共识网络中的局部共识节点可以是第一类SPV节点。为了便于理解，此处将局部共识网络中的局部共识节点称为一级SPV局部共识节点。第二类SPV节点可以是指与第一类SPV节点具有网络连接关系的局部业务节点，比如，与局部共识网络具有网络连接关系的局部业务节点，此处可以将局部业务节点称为业务SPV节点。
因此，可以通过一级SPV局部共识节点从主链上清分到与各自相关联的数据，并且，分别与各个局部共识网络具有网络连接关系的业务节点可以从对应的局部共识子链上同步数据。业务SPV节点也可以生成业务交易(称为局部共识交易)发送给对应的局部共识网络中的一级SPV局部共识节点，由一级SPV局部共识节点对局部共识交易进行打包和上链。可以理解，在局部共识网络进行共识的业务交易不会转发到主链上，而是在各自的局部共识网络中进行业务处理。业务SPV节点也是通过对应局部共识网络中的一级SPV局部共识节点在局部共识子链上清分到相关联的数据。
在本申请实施例中，还可以通过SPV节点在业务网络中创建下一级的局部共识网络(比如可以称为局部共识子网络)，如各个二级地区票据机构(如市级的税务机构)可以创建各自的局部共识子网络，局部共识子网络与对应的局部共识网络存在网络连接关系。可以理解，对于二级地区票据机构关联的局部共识子网络而言，一级地区票据机构关联的局部共识网络即视为针对二级地区票据机构的核心共识网络。局部共识网络与局部共识子网络之间的数据交互原理，与核心共识网络和局部共识网络之间的数据交互原理相同。比如，局部共识子网络中可以执行与XX市相关的票据业务交易，局部共识网络中可以执行与XX省相关的票据业务交易，从而实现区块链网络的层级划分。局部共识子网络中的局部共识子链与局部共识网络中的局部共识子链相互独立，局部共识子网络中的局部共识子链可以从局部共识网络中的局部共识子链上同步数据，并且局部共识子网络中的局部共识节点在进行区块共识时，也可以按照上述相同的状态绑定原理绑定局部共识网络中的局部共识子链的区块高度，并可以在执行局部共识子网络中的业务交易时按照上述相同的数据引用原理，从局部共识网络中的局部共识子链引用所需数据，从而在局部共识子网络中进行相关共识区块的区块共识，并将达成区块共识的前述共识区块上链至局部共识子网络中的局部共识子链。也就是说，业务网络所包括的第一类SPV节点还可以包括局部共识子网络中的局部共识节点；以及，局部共识子网络中的局部共识节点与局部共识网络中的局部共识节点具有网络连接关系，局部共识子网络中的局部共识节点，可以通过局部共识网络中的局部共识节点从对应维护的局部共识子链上同步局部共识区块，并搭建属于自己的区块链。为了便于理解，可以将局部共识子网络 中的局部共识节点称为二级SPV局部共识节点。相应地，第二类SPV节点可以包括与局部共识子网络中的局部共识节点具有网络连接关系的业务节点。
此外，若局部共识网络中产生了待在主链上进行的主链业务交易(即为全局共识交易)，比如将全局共识交易的执行结果对应的交易汇总信息上传到主链，生成交易汇总信息对应的信息上链交易，通过核心共识网络的入口将主链业务交易发送给核心共识网络中的核心共识节点，由核心共识节点对主链业务交易进行共识和执行。在本申请实施例中，业务网络还可以包括第三类SPV节点，该第三类SPV节点可以在第一类SPV节点和具有网络连接关系的共识节点进行数据交互时起到中转作用。比如，第一类SPV节点可以生成清分同步请求发送给第三类SPV节点，由第三类SPV节点将该清分同步请求转发给具有网络连接关系的共识节点，具有网络连接关系的共识节点再根据清分清分同步请求获取待同步的共识区块时，将该待同步的共识区块发送给第三类SPV节点，由第三类SPV节点将该待同步的共识区块返回给第一类SPV节点。也就是说，此处局部共识网络与核心共识网络之间可以部署一个或多个第三类SPV节点，且核心共识网络与不同局部共识节点之间的第三类SPV节点可以是不同的。局部共识网络与局部共识子网络之间可以部署一个或多个第三类SPV节点，且局部共识网络与不同局部共识子网络之间的第三类SPV节点可以是不同的。为了便于理解，此处可以将局部共识网络与核心共识网络之间的第三类SPV节点称为一级SPV节点，并将局部共识网络与局部共识子网络之间的第三类SPV节点称为二级SPV节点。
因此，可以理解，一级SPV局部共识节点在与核心共识网络中的核心共识节点进行数据交互时，可以是通过一级SPV节点进行数据交互的。也就是说，一级SPV局部共识节点可以通过一级SPV节点从主链上同步数据，如一级SPV局部共识节点发送主链清分同步请求给一级SPV节点，由一级SPV节点将主链清分同步请求转发到核心共识网络的入口，最终发送给核心共识节点，核心共识节点也可以通过一级SPV节点将要同步的数据返回给一级SPV局部共识节点。又如，一级SPV局部共识节点在生成主链业务交易时可以将该主链业务交易发送给一级SPV节点，由一级SPV节点将主链业务交易转发到核心共识网络的入口，最终发送给核心共识节点。又如，还可以是，一级SPV节点可以通过核心共识节点从主链上不断同步最新全局共识区块，并在接收到局部共识节点发送的主链清分同步请求时，从本地所同步到的数据中选取待同步全局区块，并将待同步全局区块发送给局部共识节点。可以理解，不同局部共识网络对应的一级SPV节点是不同的，且一个局部共识网络可以对应一个或多个一级SPV节点。相应地，可以根据与局部共识网络具有网络连接关系的SPV节点构建下一层级的局部共识子网络，此时局部共识网络与局部共识子网络之间存在SPV节点，比如可以称为二级SPV节点，该二级SPV节点的工作原理与一级SPV节点的工作原理等同。
例如图6a和图6b，图6a和图6b为本申请实施例提供的两种基于多层链网络的区块链框架示意图；其中，如图6a，核心共识网络600包括核心共识节点60a、60b、60c；局部共识网络610包括一级SPV局部共识节点61a、61b、61c；局部共识网络610和核心共识网络600之间可以直接进行数据交互，比如一级SPV局部共识节点61a可以生成主链清分同步请求，通过核心共识网络的入口将主链清分同步请求发送给核心共识节点60a，以通过核心共识节点60a同步主链上的数据；局部共识网络610可以与业务SPV 节点(62a、62b、...、62n)进行数据交互，比如业务SPV节点62a可以提交业务交易给一级SPV局部共识节点61a，由一级SPV局部共识节点61a将业务交易广播给其余一级SPV局部共识节点，后续可以在局部共识网络610中将该业务交易打包至区块并上链至局部共识子链，或者，局部共识网络610和核心共识网络600之间可以通过一级SPV节点进行数据交互，此处的一级SPV节点可以包括一级SPV节点63a和63b，表示服务双活，两个一级SPV节点具备的功能和权限相同。比如，一级SPV局部共识节点61a可以将生成的主链清分同步请求发送给一级SPV节点63a，由一级SPV节点63a通过核心共识网络的入口发送给核心共识节点60a，核心共识节点60a从主链上获取待同步的数据(如全局共识区块以及全局合约状态)通过核心共识网络的入口发送给一级SPV节点63a，由一级SPV节点63a返回给一级SPV局部共识节点61a。可以理解，一级SPV节点的数量可以有多个，此处仅以两个示例，实际场景中对数量不做限制。
在本申请实施例中，在图6a的基础上可以创建多个局部共识网络，实际场景中对局部共识网络的数量不做限制；另外，每个局部共识网络与核心共识网络之间都可以存在一级SPV节点，一个局部共识网络可以对应一个或多个一级SPV节点。
在本申请实施例中，如图6b，在图6a的基础上可以创建局部共识子网络620，局部共识子网络620包括二级SPV局部共识节点64a、64b、64c，该局部共识子网络620与局部共识网络610可以直接进行数据交互；比如，二级SPV局部共识节点64a可以将生成的子链清分同步请求通过局部共识网络的入口发送给一级SPV局部共识节点61a，以通过一级SPV局部共识节点61a同步局部共识子链上的数据；局部共识子网络620可以与业务SPV节点65a、65b、...65n进行数据交互；比如，业务SPV节点65a可以提交业务交易给二级SPV局部共识节点64a，由二级SPV局部共识节点64a将业务交易广播给其余二级SPV局部共识节点，后续可以在局部共识网络620中将该业务交易打包至区块并上链至局部共识子网络620中的局部共识子链。另外，在局部共识子网络620和局部共识网络610之间可以通过二级SPV节点进行数据交互，此处的二级SPV节点可以包括二级SPV节点66a和66b，表示服务双活，两个二级SPV节点具备的功能和权限相同。比如，二级SPV局部共识节点64a可以将生成的子链清分同步请求发送给二级SPV节点66a，由二级SPV节点66a通过局部共识网络的入口发送一级SPV局部共识节点61a，一级SPV局部共识节点61a从所维护的局部共识子链上获取待同步的数据(如局部共识区块以及所关联的局部合约状态)通过局部共识网络的入口发送给二级SPV节点66a，由二级SPV节点66a返回给二级SPV局部共识节点66a。可以理解，二级SPV节点的数量可以有多个，此处仅以两个示例，实际场景中对数量不做限制。
可以理解，在局部共识网络610中进行区块共识的过程可以是：一级SPV局部共识节点61a(称为局部共识节点)打包局部共识交易，并在打包局部共识交易时获取主链绑定高度和主链读数据集合，从而将主链绑定高度、主链读数据集合以及局部共识交易存储至提议区块，将该提议区块作为待共识的局部共识区块。接着，将局部共识区块广播给一级SPV局部共识节点61b和61c(称为局部验证节点)，一级SPV局部共识节点61a、61b和61c均进行相同的区块共识步骤，且所执行的区块共识步骤与局部共识节点和局部验证节点的区块共识步骤类似，本申请实施例在此不再重复描述。另外，一级SPV局部共识节点61a执行局部共识区块中的局部共识交易，得到区块共识结果；接 着验证一级SPV局部共识节点61b和61c所得到的区块共识结果与一级SPV局部共识节点61a得到的区块共识结果是否一致，若确定一致则生成指示投票赞同的投票共识结果，若确定不一致则生成指示投票反对的投票共识结果；同时，一级SPV局部共识节点61a将投票共识结果发送给一级SPV局部共识节点61b和61c，此时也会接收到一级SPV局部共识节点61b和61c所返回的投票共识结果；若一级SPV局部共识节点61a、61b、61c分别对应的投票共识结果均为投票赞同的投票共识结果，则确定达成区块共识，从而将局部共识区块上链至一级SPV局部共识节点61a所维护的局部共识子链。
相应地，一级SPV局部共识节点61b(或61c)确定达成区块共识和上链的过程，与一级SPV局部共识节点61a在确定达成区块共识时将局部共识区块上链局部共识子链的过程类似，本申请实施例在此不再重复描述。
可以理解，局部业务节点从局部共识子链上同步数据的过程，同局部共识节点从主链上同步数据的过程类似，本申请实施例在此不再重复描述。此处的局部业务节点可以是指图6a中的业务SPV节点62a，也可以是指图6b中的二级SPV局部共识节点64a。在同步局部共识子链时，获取局部业务节点发送的子链清分同步请求，局部业务节点包括局部链子账本数据库，子链清分同步请求携带局部业务节点从局部共识子链上同步到的局部区块高度(局部共识子链由局部共识节点维护，局部区块高度为局部共识区块的区块高度)，基于局部清分同步规则和局部区块高度，从局部共识子链上确定未同步给局部业务节点的局部共识区块，并从未同步给局部业务节点的局部共识区块中，选取待同步局部区块，获取待同步局部区块所关联的局部合约状态，并将待同步局部区块和所关联的局部合约状态返回给局部业务节点，以使局部业务节点将待同步共识区块以及所关联的局部合约状态写入局部链子账本数据库，局部合约状态为执行待同步局部区块中的局部共识交易所读取到的读数据集合，局部共识交易由局部共识网络的局部链上的局部共识业务合约执行，从而可以实现局部共识子链的数据同步，局部业务节点可以从同步到的数据中清分到与自身相关的业务数据。
可以理解的是，此处的局部业务节点可以是指局部共识网络的业务SPV节点(比如图6a中的业务SPV节点62a)，还可以是指局部共识网络的下一层级的局部共识子网络中的共识节点(比如图6b中的二级SPV局部共识节点64a)。子链清分同步请求所携带局部区块高度等同于第一全局共识区块的区块高度。应当理解，局部共识节点向局部业务节点所返回的局部合约状态涉及待同步共识区块从主链上所引用的数据，也就是该待同步共识区块中的主链读数据集合。此外，若局部业务节点是局部共识子网络中的共识节点，则局部业务节点还可以在该局部共识子网络中搭建独立于局部共识网络中的局部共识子链的区块链。
相应地，局部共识子网络中区块共识的过程和原理，同局部共识网络中区块共识的过程和原理类似，本申请实施例在此不再重复描述。
其中，未同步给局部业务节点的局部共识区块，是指在局部共识节点在接收到子链清分同步请求时从局部共识子链上所确定出的未同步共识区块；比如可以是局部共识子链上区块高度大于局部区块高度的局部共识区块。可以理解，此时可能确定出局部共识子链上不存在未同步给局部业务节点的局部共识区块。
其中，局部共识节点基于局部清分同步规则和局部区块高度从局部共识子链上确定 待同步局部区块的过程和原理，同核心共识节点从主链上确定待同步全局区块的过程和原理类似。局部共识节点确定待同步局部区块的过程可以是：基于局部清分同步规则和局部区块高度确定同步结果；当同步结果表示局部共识子链上不存在未同步给局部业务节点的局部共识区块时，从局部共识子链上获取具有最大局部区块高度的局部共识区块，并将具有最大局部区块高度的局部共识区块作为待同步局部区块；当同步结果表示局部共识子链上存在至少一个未同步给局部业务节点的局部共识区块时，将至少一个未同步给局部业务节点的局部共识区块，作为待同步局部区块。
可以理解，当不存在未同步给局部业务节点的局部共识区块时，表示局部共识子链上的最大局部区块高度为子链清分同步请求中所携带的区块高度，也就是说局部共识子链上的最大局部区块高度对应的局部共识区块即为局部业务节点上已同步到的最新局部共识区块。局部共识节点可以将该局部共识子链上的最大局部区块高度对应的局部共识区块返回给局部业务节点。或者，也可以生成指示未新增局部共识区块的通知信息，并将该通知信息返回给局部业务节点。此外，当确定存在未同步给局部业务节点的局部共识区块时，表示局部共识子链上此时存在新增的局部共识区块，局部共识节点可以将该新增的局部共识区块作为待同步局部区块以同步给局部业务节点。也就是说，局部业务节点可以通过局部共识节点从局部共识子链上获取到最大局部区块高度对应的局部共识区块。
可以理解，局部业务节点能够同步局部共识子链上的数据，但由于局部共识子链上的局部共识区块可以引用主链上的数据，因此局部业务节点也可以同步这部分引用的主链数据，也就是能够通过局部共识节点同步到与自身相关的主链数据，从而能够保障主链上的交易数据的安全性和隐私性，还可以便于通过主链可以对局部共识子链进行全局管理。
此外，局部共识节点还可以生成需要主链执行的业务交易，包括基于交易上链规则对局部共识交易对应的交易执行结果进行交易汇总处理，得到汇总交易信息，并生成携带汇总交易信息的信息上链交易，调用主链转发上链组件生成携带信息上链交易的主链上链请求；接着将主链上链请求发送给核心共识节点，主链上链请求用于指示核心共识节点将信息上链交易写入主链，以将汇总交易信息写入主链。其中，该交易汇总处理可以是对当前达成区块共识的局部共识区块中的交易执行结果进行交易汇总处理，还可以是对当前达成区块共识的局部共识区块及此前的局部共识区块中的交易执行结果进行交易汇总处理，在此对交易汇总处理的具体规则不做限定。比如，当局部共识交易是抽奖业务交易时，交易汇总处理用于指示将指定时间所执行抽奖业务交易得到的交易结果(比如为抽奖结果)进行汇总，得到交易汇总信息(比如，中奖人的年龄、中奖额度等统计信息)；接着生成该交易汇总信息对应的信息上链交易，以使得核心共识节点可以根据该信息上链交易将交易汇总信息写入主链。
本申请实施例提出一种针对局部共识区块的共识机制，通过该针对局部共识区块的共识机制可以生成与主链存在关联关系的局部共识区块，该关联关系基于打包至局部共识区块的主链绑定高度、主链读数据集合体现。该主链子账本数据库中的数据是从核心共识网络中的主链上所同步到的；该主链绑定高度是在打包局部共识交易时从主链上所同步到的第一全局共识区块的区块高度，主链读数据集合是从主链子账本数据库中所清 分到的用于执行局部共识区块中的局部共识交易所需读取的读数据集合，该主链读数据集合也就是在执行局部共识交易时所需从主链上引用的数据；在对局部共识区块进行区块共识时，局部共识节点对主链绑定高度和主链读数据集合进行数据审核，并在数据审核成功后进行后续的区块共识过程。通过在局部共识网络进行局部共识区块的区块共识，并将达到区块共识的局部共识区块写入局部共识子链中，从而能够搭建独立于主链以外的局部共识子链，此便于层级化管理各个业务方的业务交易的交易数据；比如，各个业务方可以分别构建各自的局部共识子链，以分别在各个局部共识子链的局部共识区块中存放与各个业务方相关的业务数据(如业务方A在执行业务交易所涉及的交易数据可以上链到局部共识子链A，业务方B在执行业务交易所涉及的交易数据可以上链到局部共识子链B)，使得在局部共识网络中所执行交易涉及的交易数据可以存储在相关联的局部共识子链中，以确保重要交易数据的安全性、隐私性以及数据隔离；此外，通过与主链存在关联关系的局部共识区块，可以使得执行该局部共识区块中的局部共识交易时可以直接快速引用主链上的数据，避免主链和局部共识子链之间繁琐的跨链流程，同时对主链绑定高度和主链读数据集合进行审核还可以使得各个局部共识节点在执行局部共识交易时保障从主链上所引用数据的一致性，以便于达成局部共识区块的区块共识，进而有助于局部共识子链的搭建和使用的便捷性。
参见图7，图7是本申请实施例提供的一种区块链数据处理方法的流程示意图，如图7所示，方法可以由局部共识网络中的局部共识节点和局部验证节点来执行；比如，该局部共识节点可以为图1所示的局部共识网络100a中任意一个共识节点(如局部共识节点10a)，该局部验证节点可以为图1所示的局部共识网络100a中除局部共识节点之外的任意一个共识节点(如10b)。方法包括步骤S701至步骤S706，下面对各步骤分别进行说明。
S701，局部共识节点在将局部共识节点中所缓存的局部共识交易打包至提议区块时，将从主链子账本数据库中所获取到的主链绑定高度和主链读数据集合一并打包至提议区块，将包含主链绑定高度、主链读数据集合以及局部共识交易的提议区块作为待共识的局部共识区块。
其中，步骤S701的具体实施方式可以参见上述实施例的相关描述。
S702，局部共识节点在对局部共识区块进行区块共识时，将局部共识区块广播给局部共识网络中的局部验证节点。
应当理解，局部验证节点可以是指局部共识网络中除局部共识节点以外的共识节点。
S703，局部共识节点对局部共识区块中的主链绑定高度、主链读数据集合进行数据审核，并在数据审核成功时对局部共识区块进行区块共识，得到区块共识结果。
其中，局部共识节点在对局部共识区块进行区块共识时，同样会执行对主链绑定高度和主链读数据集合进行数据审核的步骤。可以理解，局部共识节点在对局部共识区块进行区块共识时，可以调用局部共识网络所对应局部共识子链上的局部共识业务合约，以对局部共识区块中的主链绑定高度和主链读数据集合进行数据审核，得到数据审核结果。在数据审核结果指示数据审核成功时，再对局部共识区块进行区块共识。以及，调用局部共识业务合约执行局部共识区块中的局部共识交易，将执行局部共识交易所得到的交易执行结果作为对局部共识区块进行区块共识时的区块共识结果。
在一些实施例中，局部共识节点进行数据审核得到数据审核结果的方式可以是：调用局部共识子链上的局部共识业务合约执行以下处理：从主链子账本数据库中获取待确认区块高度；待确认区块高度为通过核心共识节点从主链上同步到的第二全局共识区块的区块高度，第二全局共识区块为进行区块共识时同步到的主链上的全局共识区块，将待确认区块高度与局部共识区块中的主链绑定高度进行对比，得到第一对比结果，根据第一对比结果确定数据审核结果。
其中，根据第一对比结果确定数据审核结果的过程可以是：在第一对比结果指示待确认区块高度小于主链绑定高度时，生成指示数据审核失败的数据审核结果；在第一对比结果指示待确认区块高度等于主链绑定高度时，确定第一全局共识区块与第二全局共识区块为同一全局共识区块，也就是说在打包局部共识交易到区块共识期间，局部共识节点未从主链上同步到全局共识区块，此时最新同步到的全局共识区块(第二全局共识区块)仍为第一全局共识区块；从而，调用局部共识业务合约在主链子账本数据库中查找与第一全局共识区块相关的读数据集合，并将读数据集合作为待确认读数据集合，将待确认读数据集合中的键值对作为第一键值对，且将局部共识区块中的主链读数据集合的键值对作为第二键值对，将第一键值对和第二键值对进行对比，得到第二对比结果，将第二对比结果作为数据审核结果。可以理解，与第一全局共识区块相关的读数据集合也就是从主链子账本数据库当前所同步到的数据中查找得到的，且与第一全局共识区块相关的读数据集合中的每个键值对的键值数据与主链读数据集合中的每个键值对的键值数据是一致的，也就是说可以根据主链读数据集合中的每个键值对的键值数据从主链子账本数据库中查找对应记录的值数据，以将主链读数据集合中的每个键值对的键值数据和对应的值数据作为与第一全局共识区块相关的读数据集合。
因此，在数据审核结果指示数据审核成功时，调用局部共识业务合约执行局部共识区块中的局部共识交易，将执行局部共识交易所得到的交易执行结果作为对局部共识区块进行区块共识时的区块共识结果；也就是说，当数据审核结果指示第一键值对与第二键值对保持一致时，表示该数据审核结果指示数据审核成功，可以调用局部共识业务合约读取局部共识区块中的主链读数据集合，通过读取到的主链读数据集合执行局部共识区块中的区块共识交易，以将执行局部共识交易所得到的交易执行结果作为对局部共识区块进行区块共识时的区块共识结果。可以理解，当数据审核结果指示第一键值对与第二键值对保持不一致时，表示该数据审核结果指示数据审核失败，则不执行后续共识过程。
应当理解，当第一对比结果指示待确认区块高度大于主链绑定高度时，确定第一全局共识区块与第二全局共识区块为不同全局共识区块，且局部共识节点已从主链上同步到第一全局共识区块，因此可以调用局部共识业务合约在主链子账本数据库中查找与第一全局共识区块相关联的读数据集合，将读数据集合作为待确认读数据集合，并按照上述过程对待确认读数据集合和主链读数据集合进行对比以得到数据审核结果。可以理解，在查找与第一全局共识区块相关联的读数据集合时，是在主链子账本数据库中所同步到的第一全局共识区块、以及在第一全局共识区块所关联的全局合约状态数据中进行查找，该查找方式可以参见上述相关描述。也就是说，当待确认区块高度大于或等于主链绑定高度时，可以从主链子账本数据库中查找与第一全局共识区块相关联的读数据集合，以 作为待确认读数据集合，该待确认读数据集合用于验证主链读数据集合的一致性。
可以理解，在打包局部共识交易至区块共识期间，可能会从主链上重新同步到全局共识区块，也就是这里的第二全局共识区块，可以对比第二全局共识区块的区块高度与第一全局共识区块的区块高度，当第二全局共识区块的区块高度大于第一全局共识区块的区块高度(第一对比结果指示待确认区块高度大于主链绑定高度)时，确定第一全局共识区块与第二全局共识区块为不同全局共识区块，即第二全局共识区块为新同步到的共识区块，将与第二全局共识区块相关联的第二全局合约状态数据添加至主链子账本数据库。该第二全局合约状态数据为执行第二全局共识区块中的全局共识交易时所读取到的读数据集合，且该执行通过在核心共识网络中调用主链上的全局共识业务合约实现。应当理解，待确认数据集合是基于主链子账本数据库中的与第一全局共识区块相关联的第一全局合约状态数据得到。
可以理解，当得到区块共识结果后，需要对该区块共识结果进行投票共识，也就是确定局部验证节点上的区块共识结果与局部共识节点上的区块共识结果是否一致，比如当一定数量的区块共识结果相同时，表示一致，则可以生成指示投票赞成的投票共识结果；当没有达到一定数量的区块共识结果相同时，表示不一致，则可以生成指示投票反对的投票共识结果。局部共识节点可以将该投票共识节点发送给局部验证节点。
S704，局部验证节点对局部共识区块中的主链绑定高度、主链读数据集合进行数据审核，并在数据审核成功时对执行局部共识交易所得到的交易执行结果进行投票共识，得到投票共识结果。
可以理解，局部验证节点对局部共识区块中的主链绑定高度和主链读数据集合进行数据审核的过程和原理，与局部共识节点进行数据审核的过程和原理相同。也就是确定在区块共识时所同步到的全局共识区块的区块高度是否大于或等于主链绑定高度，若大于或等于主链绑定高度，则从主链子账本数据库中查找待确认读数据集，并对待确认读数据集与主链读数据集是否一致，若一致则表示数据审核成功。其中，当数据审核成功，则表示具有投票共识权限，若数据审核成功，则不会进行投票共识，也就不会产生投票共识结果。
可以理解，局部验证节点执行局部共识交易得到交易执行结果的过程也就是局部验证节点对局部共识区块进行区块共识得到区块共识结果的过程。因此对交易执行结果进行投票共识可以是，确定其他局部共识节点上的交易执行结果是否与局部验证节点上的交易执行结果一致，若一致则生成指示投票赞成的投票共识结果。此外，在局部验证节点得到投票共识结果后会将该投票共识结果发送给其他局部共识节点，同时局部验证节点也会接收到其他局部共识节点发送的投票共识节点。比如，参见图8，图8是本申请实施例提供的一种区块共识的交互示意图；局部共识网络中包括局部共识节点70a、70b和70c，局部共识节点70a在得到交易执行结果后验证局部共识节点70b和70c上的交易执行结果是否与自身的交易执行结果是否一致并生成相应的投票共识结果，并且将投票共识结果发送给局部共识节点70b和70c、局部共识节点70b在得到交易执行结果后验证局部共识节点70a和70c上的交易执行结果是否与自身的交易执行结果是否一致并生成相应的投票共识结果，并且将投票共识结果发送给局部共识节点70a和70c、局部共识节点70c在得到交易执行结果后验证局部共识节点70a和70b上的交易执行结果是 否与自身的交易执行结果是否一致并生成相应的投票共识结果，并且将投票共识结果发送给局部共识节点70a和70b。
S705，局部验证节点将投票共识结果返回给局部共识节点。
S706，局部共识节点基于区块共识结果和投票共识结果确定达成区块共识时，将局部共识区块上链至局部共识网络对应的局部共识子链，且将局部共识区块写入独立于主链子账本数据库的局部共识账本数据库。
可以理解，局部共识节点可以根据区块共识结果确定对应的投票共识结果，并根据自身得到的投票共识结果和接收到的投票共识结果确定是否达成区块共识，若确定达成区块共识，则将该局部共识区块上链至局部共识区块对应的局部共识子链，且将局部共识区块写入独立主链子账本数据库的局部共识账本数据库中。相应地的，局部验证节点也会确定达成区块共识，并将局部共识区块上链至对应维护的局部共识子链，且将局部共识区块写入本地的局部共识账本数据库。
继续参见图8，该交互过程包括S1至S23，下面对各步骤分别进行说明。
S1、局部共识节点70a将局部共识区块广播给局部共识节点70b。
S2、局部共识节点70a将局部共识区块广播给局部共识节点70c。
S3、局部共识节点70a对局部共识节点中的主链绑定高度和主链读数据集合进行数据审核，并在数据审核成功后执行局部共识区块中的局部共识交易，得到交易执行结果a。
S4、局部共识节点70b对局部共识节点中的主链绑定高度和主链读数据集合进行数据审核，并在数据审核成功后执行局部共识区块中的局部共识交易，得到交易执行结果b。
S5、局部共识节点70c对局部共识节点中的主链绑定高度和主链读数据集合进行数据审核，并在数据审核成功后执行局部共识区块中的局部共识交易，得到交易执行结果c。
S6、局部共识节点70a将交易执行结果a广播给局部共识节点70b。
S7、局部共识节点70a将交易执行结果a广播给局部共识节点70c。
S8、局部共识节点70b将交易执行结果b广播给局部共识节点70a。
S9、局部共识节点70b将交易执行结果b广播给局部共识节点70c。
S10、局部共识节点70c将交易执行结果c广播给局部共识节点70a。
S11、局部共识节点70c将交易执行结果c广播给局部共识节点70b。
S12、局部共识节点70a根据交易执行结果b和交易执行结果c对交易执行结果a进行投票共识，生成投票共识结果a。
需要说明的是，投票共识结果a表示交易执行结果b和交易执行结果c是否与交易执行结果a一致。
S13、局部共识节点70b根据交易执行结果a和交易执行结果c对交易执行结果b进行投票共识，生成投票共识结果b。
需要说明的是，投票共识结果b表示交易执行结果a和交易执行结果c是否与交易执行结果b一致。
S14、局部共识节点70c根据交易执行结果a和交易执行结果b对交易执行结果c 进行投票共识，生成投票共识结果c。
需要说明的是，投票共识结果c表示交易执行结果a和交易执行结果b是否与交易执行结果c一致。
S15、局部共识节点70a将投票共识结果a发送给局部共识节点70b。
S16、局部共识节点70a将投票共识结果a发送给局部共识节点70c。
S17、局部共识节点70b将投票共识结果b发送给局部共识节点70a。
S18、局部共识节点70b将投票共识结果b发送给局部共识节点70c。
S19、局部共识节点70c将投票共识结果c发送给局部共识节点70a。
S20、局部共识节点70c将投票共识结果c发送给局部共识节点70b。
S21、局部共识节点70a若根据投票共识结果a-c确定达成区块共识，则将局部共识区块上链至所维护的局部共识子链，并写入本地的主链子账本数据库。
S22、局部共识节点70b若根据投票共识结果a-c确定达成区块共识，则将局部共识区块上链至所维护的局部共识子链，并写入本地的主链子账本数据库。
S23、局部共识节点70c若根据投票共识结果a-c确定达成区块共识，则将局部共识区块上链至所维护的局部共识子链，并写入本地的主链子账本数据库。
参见图9，图9是本申请实施例提供的一种区块链数据处理方法的流程示意图，如图9所示，方法可以由核心共识网络中的核心共识节点来执行；比如，核心共识节点可以为图1所示的核心共识网络200a中任意一个共识节点。方法可以包括步骤S901至步骤S904，下面对各步骤分别进行说明。
S901，获取局部共识网络中的局部共识节点发送的主链清分同步请求。
可以理解，主链清分同步请求用于请求核心共识节点从主链上获取待同步给局部共识节点的数据，并将待同步给局部共识节点的数据返回给局部共识节点。该主链清分同步请求可以携带第一全局共识区块的区块高度。该第一全局共识区块可以为局部共识节点在打包局部共识交易时从主链上所同步到的全局共识区块；比如，局部共识节点在打包局部共识交易时可以从主链子账本数据库中获取当前最新同步到的全局共识区块的区块高度，并将该获取到的最新同步到的全局共识区块作为第一全局共识区块，以及将该最新同步到的全局共识区块的区块高度写入主链清分同步请求。
S902，基于全局清分同步规则和第一全局共识区块的区块高度从主链上确定未同步给局部共识节点的全局共识区块，并从未同步给局部共识节点的全局共识区块中选取待同步全局区块。
可以理解，核心共识节点在确定未同步给局部共识节点的全局共识区块时，可以是将主链上区块高度大于第一全局共识区块的区块高度的全局共识区块，作为未同步给局部共识节点的全局共识区块。
在本申请实施例中，核心共识节点确定待同步全局区块的过程可以是：若确定主链上不存在未同步给局部共识节点的全局共识区块，则从主链上获取最大全局区块高度对应的全局共识区块，并将最大全局区块高度对应的全局共识区块作为待同步全局区块；若确定主链上存在至少一个未同步给局部共识节点的全局共识区块，则将至少一个未同步给局部共识节点的全局共识区块作为待同步全局区块。
可以理解，当主链上不存在未同步给局部共识节点的全局共识区块时，表示主链上 的最大全局区块高度为主链清分同步请求中所携带的区块高度，也就是说主链上的最大全局区块高度对应的局部共识区块即为局部共识节点上已同步到的第一全局共识区块。此时，核心共识节点可以将主链上的最大全局区块高度对应的全局共识区块返回给局部共识节点，即将主链上的第一全局共识区块返回给局部共识节点；也可以生成指示未新增全局共识区块的通知信息，并将该通知信息返回给局部共识节点。此外，当确定存在未同步给局部共识节点的全局共识区块时，表示主链上此时存在新增的全局共识区块，核心共识节点将该新增的全局共识区块作为待同步全局区块以同步给局部共识节点。也就是说，局部共识节点可以通过核心共识节点从主链上获取到最大全局区块高度对应的全局共识区块，即为局部共识节点从主链上同步最新的全局共识区块。
在本申请实施例的局部共识网络中，由于用于投票共识的共识节点同步到的区块高度大于或等于第一全局共识区块的区块高度，然而存在共识节点未及时同步到该最新全局共识区块的情况，从而存在共识节点无法进行投票共识。因此，核心共识节点在将主链上的全局共识区块同步给局部共识节点时，可以通过缓冲区块高度，降低每个局部共识节点从主链所同步的全局共识区块的区块高度。比如，主链上的全局共识区块的区块高度为100，缓冲区块高度为20，则此时局部共识节点可以从主链上所同步的全局共识区块的区块高度为80。
因此，选取待同步全局区块的过程可以是：获取缓冲区块高度，并将第一全局共识区块的区块高度与缓冲区块高度之和作为目标区块高度，基于未同步给局部共识节点的全局共识区块的区块高度和目标区块高度确定全局同步高度，从未同步给局部共识节点的全局共识区块中获取全局同步高度对应的全局共识区块，并将全局同步高度对应的全局共识区块作为待同步全局区块。
可以理解，确定全局同步高度的过程可以是：若未同步给局部共识节点的全局共识区块的区块高度等于目标区块高度，则将第一全局共识区块的区块高度作为全局同步高度；若未同步给局部共识节点的全局共识区块的区块高度大于目标区块高度，则获取第一全局共识区块的区块高度至待同步区块高度之间的区块高度，并将第一全局共识区块的区块高度至待同步区块高度之间的区块高度作为全局同步高度；待同步区块高度是指新增区块高度与第一全局共识区块的区块高度的高度之和，新增区块高度是指主链上的全局共识区块的最大全局区块高度和目标区块高度之间的高度差值。
也就是说，当确定未同步给局部共识节点的全局共识区块的区块高度大于目标区块高度时，表示在上一次同步数据至这一次同步数据期间，主链上存在新增的全局共识区块，此时主链的区块高度增加，且主链的区块高度与第一全局共识区块的区块高度之差大于缓冲区块高度，因此可以根据上一次同步数据至这一次同步数据期间所新增的全局共识区块的数量确定待同步全局区块。也就是说，上一次同步数据至这一次同步数据期间新增了L个全局共识区块，可以依次同步L个全局共识区块给局部共识节点，其中，L为正整数。
例如，第一全局共识区块的区块高度为80，缓冲区块高度为20，则目标区块高度为100，若此时主链上的全局共识区块的区块高度为103，则表示主链上在此期间新增了3个全局共识区块，因此新增区块高度为3；此时，从第一全局共识区块的下一个全局共识区块开始，依次同步3个全局共识区块给局部共识节点，也就是说全局同步高度 为81、82和83。
相应地，当确定未同步给局部共识节点的全局共识区块的区块高度等于目标区块高度时，则表示在上一次同步数据至这一次同步数据期间，主链上不存在新增的全局共识区块，此时主链的区块高度未增加，且主链的区块高度与第一全局共识区块的区块高度之差等于缓冲区块高度；因此可以从主链上获取第一全局共识区块并同步给局部共识节点，或者生成指示未新增全局共识区块的通知信息，并将该通知信息返回给局部共识节点。通过上述过程可以完成局部共识节点上的主链数据同步。可以理解，局部共识网络中的每个局部共识节点的主链数据同步过程同理。
S903，从主链上获取待同步全局区块、以及待同步全局区块所关联的全局合约状态。
可以理解，全局合约状态为执行待同步全局区块中的全局共识交易时所读取到的读数据集合，全局共识交易由核心共识网络中主链上的全局共识业务合约执行。
S904，将待同步全局区块、以及待同步全局区块所关联的全局合约状态返回给局部共识节点。
可以理解，当将待同步全局区块和待同步全局区块所关联的全局合约状态返回给局部共识节点时，若此时处于局部共识节点打包局部共识交易和区块共识期间，则该待同步全局区块可以是局部共识节点上所同步到的第二全局共识区块。局部共识节点可以将待同步全局区块和全局合约状态存储在局部共识节点中的主链子账本数据库中。
本申请实施例还提供一种区块链数据处理方法，该方法由核心共识网络中的核心共识节点执行，核心共识网络部署在多层链网络中，多层链网络中与核心共识网络独立的业务网络部署有局部共识网络，局部共识网络包括局部共识节点，该方法包括：获取局部共识节点发送的主链同步请求，主链同步请求携带第三全局共识区块的区块高度；第三全局共识区块为局部共识节点在同步到第一全局共识区块之前从主链上同步到的全局共识区块；从主链上，将区块高度大于第三全局共识区块的区块高度的全局共识区块，确定为未同步给局部共识节点的第一全局共识区块；从主链上获取第一全局共识区块的第一全局合约状态；第一全局合约状态为执行第一全局共识区块中的全局共识交易时所读取到的读数据集合；将第一全局共识区块、以及第一全局合约状态返回给局部共识节点，局部共识节点用于基于第一全局共识区块的区块高度和第一全局合约状态，将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，并在基于局部共识网络对局部共识区块达成共识时，将局部共识区块上链至局部共识网络中。
参见图10，图10是一种区块链网络的分层结构示意图。如图10所示的分层结构应用于区块链电子票据系统，在该区块链电子票据系统所对应的区块链网络中，包含部署在公网中的业务网络1000a和部署在私有云中的共识网络2000a。
在如图10所示的业务网络1000a中，部署有多个业务节点，示例性示出了业务节点110a、业务节点110b、业务节点110c、业务节点110d、业务节点110e、业务节点110f、业务节点110g、…、业务节点110n。其中，这里不对部署在业务网络1000a中的业务节点的数量进行限定。应当理解，处于业务网络1000a中的业务节点不需要参与记账。此外，运行在该业务网络1000a中的各个业务节点均可以通过网络通信的形式访问一个或者多个共识网络，各个共识网络之间也可以通过网络通信的形式进行数据交互。
应当理解，在如图10所示的共识网络2000a中，部署有多个共识节点，示例性示 出了共识节点211a、共识节点211b、共识节点211c和共识节点211d，这里不对部署在共识网络2000a中的共识节点的数量进行限定。此外，如图10所示，对于运行在该共识网络2000a中的多个共识节点而言，共同维护区块链211e。
为便于理解，本申请实施例可以将位于图10对应的区块链电子票据系统中的业务节点和共识节点统称为区块链节点(简称为节点)，并可以将参与构成图10对应的区块链电子票据系统的共识网络2000a称为核心共识网络，以及可以将图10的核心共识网络中的各个节点统称为核心共识节点。可以理解的是，在图10对应的区块链电子票据系统中，业务网络与共识网络之间可以通过路由边界进行交互。
在图10的区块链电子票据系统中，核心共识节点用于在对应区块链所在的核心共识网络中进行共识，也就是说核心共识节点为核心共识网络中的共识节点。将图10中的核心共识网络中的交易数据写入对应区块链账本(例如，分布式数据库)的过程可以为：客户端发送交易数据至某个业务节点，随后该交易数据以接力棒的方式在区块链网络内的业务网络中的业务节点之间传递，直到区块链网络内的核心共识网络中的共识节点(例如，共识网络2000a中的共识节点211b)收到该交易数据；此时，共识节点(例如，共识网络2000a中的共识节点211b)再将该交易数据打包进区块，以在其他共识节点之间进行共识；并在达成共识时，将该区块写入自己所在核心共识网络(例如，共识网络2000a)的分布式数据库。
可以理解的是，在图10的区块链电子票据系统中，可以在核心共识网络的区块链上部署智能合约，该智能合约在区块链电子票据系统中为一种由各区块链节点(即各共识节点)执行的代码，通过该智能合约可以执行任意逻辑并得到结果。比如，当通过客户端接收到交易业务请求时，调用相应核心共识网络(例如，共识网络2000a)的区块链(例如，区块链211e)上已经部署的智能合约，以响应交易业务请求。另外，智能合约可以通过合约调用地址、合约标识号(Identity Document，ID)或合约名称来进行区分，而在客户端发起的交易业务请求中，也可以携带智能合约的合约调用地址或者合约标识号或合约名称，以此指定需要运行的智能合约。
在图10中，业务网络中的业务节点可以将该交易业务请求发送至相应核心共识网络中的共识节点(例如，共识节点211a)，以通过相应核心共识网络的链入口对该发送交易业务请求进行身份鉴权，并在身份鉴权成功时授权将该交易业务请求发送至相应核心共识网络中的其他共识节点(例如，共识节点211b)，以调用这些共识节点(例如，图10所示的共识节点211a和共识节点211b)中运行的智能合约执行该用户所请求的交易业务。
在图10示出的区块链网络的分层结构的基础上，本申请实施例还提供一种多层区块链，该多层区块链中包括主链和该主链下的局部共识子链。其中，主链可以通过图10的区块链网络的分层结构中的共识网络中的核心共识节点进行维护，用于维护该主链下的局部共识子链的局部共识节点可以位于业务网络中，局部共识子链也可以称为局部子链、局部链等。可以理解的是，该主链下的局部共识子链的数量可以为一个或多个，每个局部共识子链所对应的局部共识网络可以用于处理一个区域的业务节点所提交的交易，且不同局部共识网络可以用于处理不同区域的业务节点所提交的交易；主链所对应的核心共识网络可以用于处理全局性的交易或者各个局部共识子链提交的汇总信息。应 当理解，在多层区块链中，一个局部共识子链上通常存储与对应局部共识子链相关联的交易，即不同区域内的业务节点所关联的交易存储在不同的局部共识子链上；因此，当对各个区域的业务节点所关联的交易进行归档时，可以分别对不同区域所对应的局部共识子链上的交易进行归档，以实现对不同区域内的业务节点相关联的交易分别进行归档的可控性，并且可以保证归档时的数据隔离性，进而确保数据归档时的安全性。
例如，在电子票据系统中，主链所对应的核心共识网络用于进行全国的票据业务处理；并且，在该主链下可以针对每个省级区域部署一个局部共识子链，每个局部共识子链所对应的局部共识网络用于与省级区域内业务节点进行数据交互，以进行省级区域内的票据业务处理；该用于进行省级区域内的票据业务处理的局部共识网络也可以称为省级局部共识网络，省级局部共识网络所维护的局部共识子链可以称为省级局部共识子链。另外，在省级局部共识网络下还可以细分更细粒度(相比于省级局部共识网络对应的粒度)的区域性的局部共识网络；如在省级局部共识子链下可以针对每个区级区域部署一个局部共识子链(可以称为区级局部共识子链)，每个区级局部共识子链所对应的局部共识网络(可以称为区级局部共识网络)可以用于与区级区域内的业务节点进行数据交互，以进行区级区域内的票据业务处理。
参见图11，图11是本申请实施例提供的一种多层区块链网络的结构示意图。如图11所示，在多层区块链网络中，可以包括局部共识网络21以及核心共识网络22。其中，局部共识网络21(比如，省级局部共识网络)可以用于维护局部共识子链，并对一级(比如，省级)区域内的业务节点提交的业务交易(比如，电子票据业务交易)进行处理。其中，局部共识网络21中的共识节点可以为轻量级节点(SPV节点)，又称为一级SPV局部共识节点(也称为局部共识节点)，例如图11所示的一级SPV局部共识节点21a、21b、21c、21d和21e。可以理解的是，在多层区块链网络中也可以包括多个局部共识网络，以用于进行不同一级区域的业务交易的处理，此处仅以局部共识网络21作为示例进行描述，其他一级区域对应的局部共识网络可以参照该局部共识网络21的相关描述。
核心共识网络22用于维护多层区块链中的主链，并对整体(比如，全国)的电子票据业务进行处理。核心共识网络中的区块链节点可以称为核心共识节点，例如图11所示的核心共识节点22a、22b和22c。可以理解的是，局部共识网络21可以与核心共识网络22之间可以进行数据交互，从而可以在该局部共识网络与核心共识网络相互协作的前提下，构造一个安全且高效的业务流系统。可以理解的是，基于多层区块链网络的电子票据系统，有助于层级化地业务处理，可以保障各区域相对独立地运行本区域级别的业务，降低主链上的业务流量。另外，在起到数据隔离，业务隐私隔离，合法合规的前提下，还能够减少核心共识网络所承载的业务，在提升全局任务的执行效率的情况下，实现全局管理。
在多层区块链网络中，局部共识网络21与核心共识网络22之间可以通过一级主链SPV节点进行数据交互。在多层区块链网络中，可以包括多个一级主链SPV节点(如图11所示的一级主链SPV节点23a和23b)，各个一级主链SPV节点的角色、数据和权限是完全相同的。例如，一级主链SPV节点可以将核心共识网络所维护的主链上的账本数据同步至局部共识网络中的局部共识节点，以使局部共识节点可以基于主链的账 本数据进行业务处理。
可以理解的是，一级主链SPV节点也可以接收各个业务对象通过客户端提交的主链业务交易；例如，业务对象在对局部共识子链进行归档时，可以提交用于指示对局部共识子链上的局部共识数据进行归档的归档配置交易，进而一级主链SPV节点可以将接收到的归档配置交易转发到核心共识网络入口25，以使核心共识网络入口25将接收到的归档配置交易转发至用于处理该业务交易的核心共识节点，例如图11中的核心共识节点22a、22b和22c。在本申请实施例中，一级主链SPV节点还可以接收局部共识节点发送的业务交易，并将局部共识节点发送的业务交易转发至核心共识网络入口25；例如，在归档业务的执行过程中，一级主链SPV节点可以接收局部共识节点(如11所示的一级SPV局部共识节点21a)基于待进行归档的局部共识数据的摘要信息确定的摘要发送交易(称为第一摘要发送交易或第二摘要发送交易)，并将该摘要发送交易转发至核心共识网络入口25，以使核心共识网络入口25可以将接收到的摘要发送交易转发至核心共识节点。
可以理解的是，多层区块链网络中还可以包括业务SPV节点，如图11中的业务SPV节点24a、24c和24b。业务SPV节点可以为局部共识网络21所对应的区域内的业务节点，并且可以与局部共识网络21进行数据交互以进行区域性的业务处理。例如，局部共识网络中的一级SPV局部共识节点(如图11所示的一级SPV局部共识节点21a)可以接收业务SPV节点(如图11所示的业务SPV节点24a)发送的针对局部共识子链的业务交易(也称局部业务交易)，进而一级SPV局部共识节点(如图11所示的一级SPV局部共识节点21a)验证接收到的局部业务交易的合法性，并对验证通过的局部业务交易进行打包共识，以将局部业务交易上链至该一级局部共识子链。
可以理解的是，提交至局部共识网络21的业务交易不会转发到核心共识网络，而是在局部共识网络中完成业务处理。当然也可以把局部共识网络中的汇总信息上传至核心共识网络中。例如，局部共识网络21可以执行根据发票进行抽奖的业务，在接收到针对局部共识子链21的抽奖业务交易后，局部共识网络21中的一级SPV局部共识节点(如图11所示的一级SPV局部共识节点21a)不会将每个抽奖业务交易转发至核心共识网络，但是可以在完成一个周期的抽奖业务后，将针对这一周期内抽奖的结果进行汇总，如汇总在这一周期内针对每个奖项抽中的次数等信息，然后将汇总信息上传至核心共识网络22。
可以理解的是，一级局部共识网络21可以同步主链上的账本数据，并对清分得到的与自身相关联的账本数据进行存储，从而局部共识网络在进行局部业务交易的处理时，可以引用从主链上同步下来的数据，如主链执行区块中交易时所用到的合约的合约状态的读值集合(Read Key-Value Set)。例如，业务对象基于在主链上开具的电子票据进行抽奖，且抽奖业务交易在局部共识网络中进行，则局部共识节点可以从自身存储的从主链上同步下来的数据中确定抽奖业务交易所需要的相关数据，如可以参与抽奖的企业名单、以及参与抽奖的比例等数据，进而基于从主链同步下来的与抽奖业务交易相关的数据进行抽奖业务交易的处理。
可以理解的是，在一级局部共识网络之外，是下一级的局部共识网络(如省级局部共识网络下还可以包括区级局部共识网络)、以及业务SPV节点，这些节点不再同步主 链的账本数据，但可以从一级局部共识网络中间接获得业务相关的主链业务信息；同时，这些节点可以同步一级局部共识网络的账本数据，同样以安全SPV数据清分的方式获得与自身(如区级局部共识网络、业务SPV节点)相关的账本数据。
为了便于理解，请参见图12，图12是本申请实施例提供的一种局部共识节点的结构示意图。如图12所示，局部共识节点300a可以为局部共识网络中的任一局部共识节点，例如图11所示的局部共识网络21中的一级SPV局部共识节点21a、21b等。局部共识节点300a可以包括区域31和区域32所示中的组件，区域31中的组件用于接收局部业务交易，将局部业务交易打包成区块，并对打包得到的区块进行区块共识和上链，得到局部共识子链上的局部共识区块；区域32中的组件用于同步主链上的数据，并从所同步的主链数据中清分到与自身相关的主链数据(比如，在执行局部业务交易时从引用的主链上的合约状态)，以及还可以生成待核心共识网络执行的业务交易，并将待核心共识网络执行的业务交易发送至核心共识网络。
可以理解的是，局部共识节点300a可以通过主链清分同步组件327从核心共识网络33中(可以为核心共识网络33中的核心共识节点)同步主链上的全局共识区块、以及与全局共识区块关联的合约状态、以及账本数据(记为主链同步数据)，并基于局部共识节点300a所维护的局部共识子链的链标识，从主链同步数据中清分出与局部共识节点300a相关联的数据，也称为与局部共识节点300a所维护的局部共识子链相关联的数据，并将清分得到的与局部共识节点相关联的主链同步数据写入主链子账本数据库329。应当理解，主链子账本数据库329可以用于存储从主链上同步到的全局共识区块中所清分到的与局部共识节点相关联的账本数据；
可以理解的是，局部共识节点300a在生成待上链至主链的业务交易时，可以触发主链共识RPC组件325调用主链转发上链组件326，以将待上链至主链的业务交易转发至核心共识网络33，进而核心共识网络33中的核心共识节点可以将接收到的业务交易写入主链；比如可以是由主链共识RPC组件325对待上链至主链的摘要发送交易进行交易校验，并通过主链共识RPC组件325调用主链转发上链组件326，以将交易校验成功的摘要发送交易转发至核心共识网络33。在本申请实施例中，局部共识节点300a还可以通过主链转发上链组件326将待发送至核心共识网络的业务交易发送至一级主链SPV节点，进而一级主链SPV节点将业务交易转发至核心共识网络入口，然后核心共识网络入口将业务交易转发至用于处理该业务交易的核心共识节点。
可以理解的是，局部共识节点300a在接收到局部业务交易(比如，由业务对象通过业务节点发送的局部共识交易)时，可以调用局部子链共识RPC组件311对局部共识交易进行交易校验并放入交易池中，然后通过局部子链共识RPC组件311调用局部子链共识组件312从交易池中获取所缓存的局部业务交易，由局部子链共识组件312将获取到的局部业务交易进行区块打包得到区块提案(Proposal，称为提议区块)，此时可以通过局部子链共识组件312调用主链合约状态读取组件328，以从主链子账本数据库中获取主链绑定高度和主链读数据集合，并由局部子链共识组件312将获取到的主链绑定高度和主链读数据集合一并打包至区块提案，从而使得区块提案可以通过主链绑定高度与主链进行状态绑定，并且通过主链读数据集合对主链数据进行引用；由于此时的区块提案为待共识的局部共识区块，进而局部子链共识组件312在对待共识的局部共识区 块进行区块共识时，可以将待共识的局部共识区块广播给局部共识网络中的局部验证节点以对待共识的局部共识区块进行投票共识，若投票达成一致，则可以将该投票达成一致的局部共识区块作为局部共识子链上的局部共识区块。可以理解的是，局部共识子链上的局部共识数据(如局部共识区块的账本数据、局部子链上的合约的合约状态)可以存储于局部共识节点300a中的局部共识账本数据库314。
可以理解的是，局部共识节点300a在通过局部子链共识组件312对局部共识区块进行审核投票时，除了对于区块头信息，每个交易的格式，签名，有效性等进行常规检查之外，还可以对局部共识区块中的主链绑定高度和主链读数据集合进行数据审核，该数据审核的过程与图2中所描述的数据审核过程类似，本申请实施例在此不再重复描述。在本申请实施例中，为了解决主链绑定高度过于新而引发太多(大于节点数量阈值)节点无法投票的问题，主链绑定高度比最新的主链区块高度低一定阈值，如至少低20个区块高度。
可以理解的是，局部共识子链300a可以通过局部链交易合约执行组件313调用对应的业务交易合约进行业务处理。例如，局部共识节点在检测到归档任务事件时，可以通过局部链交易合约执行组件313调用用于进行归档任务处理的合约进行数据归档。
可以理解的是，局部共识节点300a中还可以包括任务触发器34，该任务触发器34可以在检测到主链清分同步组件327清分到任务事件时被触发，进而任务触发器可以判断任务事件的类型，并基于判断出的类型进行任务事件的调度以执行对应的任务。例如，主链清分同步组件327可以清分得到与局部共识节点所维护的局部共识子链相匹配的任务事件，进而任务触发器可以检测清分得到的任务事件所对应的类型，在任务触发器检测到任务事件为归档任务事件时，触发局部链交易合约执行组件313调用局部共识子链上用于处理归档任务事件的目标归档业务合约，以对该归档任务事件进行处理。在本申请实施例中，任务触发器34还可以在进行任务处理的过程中进行信息转发和调度。例如，局部共识节点300a可以通过任务触发器34将待归档的局部共识数据发送至远程备份设备35(比如，服务器)；又如，局部共识节点300a可以通过任务触发器34触发主链转发上链组件326对待发送至核心共识网络33的交易进行上传。
基于图12，本申请实施例提出一种多层区块链数据处理方案，可以由包含主链清分同步组件的局部共识节点(如图12中的300a)执行；局部共识节点在通过主链清分同步组件从主链上同步到的第一区块中清分到归档任务事件时，将待进行归档的局部共识数据对应的摘要(如区块数据摘要)发送至主链对应的核心共识节点，并在通过主链清分同步组件从主链上同步到第二区块中清分到摘要确认事件时，将待进行归档的局部共识数据(如待备份账本数据)发送至远程备份设备进行备份；然后局部共识节点在接收到远程备份设备返回的远程备份签名(称为第一备份签名)时，将远程备份签名发送至核心共识节点，以使核心共识节点在对摘要与远程备份签名比对成功时，确定已将待进行归档的局部共识数据备份至远程备份设备。
本申请实施例可以通过多层区块链之间的相互协作，控制局部共识节点根据当前获取到的归档任务命令对自己本地的局部共识数据(例如，局部共识节点自己本地所存储的归档区块的账本数据)进行归档，以实现对局部共识子链上的局部共识数据进行数据归档时的可控性。另外，由于局部共识节点在将自己本地的账本数据备份至远程备份设 备之前，是将自己本地所存储的归档区块的摘要通过核心共识节点上链至主链，相比于将自己本地所存储的归档区块中的交易的原文通过核心共识节点上链至主链，可以确保局部共识节点自己本地所执行交易的原文的不可同步性，从而在对局部共识子链上的局部共识数据进行数据归档时，能够确保局部共识节点上所执行的交易的隐私性和安全性。另外，在数据归档过程中，核心共识节点还可以对摘要和第一备份签名进行对比，进而可以在对局部共识子链上的局部共识数据的归档过程中，确保备份在远程备份设备上的账本备份信息的数据安全性。
下面结合图示对局部共识子链上的局部共识数据的归档过程进行阐述。请参见图13，图13是本申请是实施例提供的一种多层区块链数据处理过程的流程示意图。此处以对局部共识子链上的账本数据进行归档的过程为例进行介绍。首先，核心共识节点接收由业务对象触发的归档任务命令所确定的归档配置交易(步骤S1301)；然后，核心共识节点将包含归档配置交易的第一区块同步至局部共识节点(步骤S1302)；该第一区块属于主链上的主链共识区块；局部共识节点可以通过主链清分同步组件(如图12所示的主链清分同步组件327)从第一区块中清分到与局部共识子链的链标识相匹配的归档任务事件；在归档任务事件所指示的归档任务命令为账本归档命令时，局部共识节点基于账本归档命令将局部共识子链上待进行归档的局部共识区块作为归档区块(步骤S1303)；进而局部共识节点可以确定归档区块对应的区块数据摘要，这里，局部共识节点可以通过任务触发器(如图12所示的任务触发器34)触发局部链交易合约执行组件(如图12所示的局部链交易合约执行组件313)确定区块数据摘要；接着，局部共识节点将归档区块的区块数据摘要发送给核心共识节点(步骤S1304)，局部共识节点可以通过任务触发器触发主链转发上链组件(如图12所示的主链转发上链组件326)将区块数据摘要发送至核心共识节点。
在接收到区块数据摘要后，核心共识节点在将区块数据摘要对应的第一摘要确认事件打包至第二区块时，将第二区块写入主链(步骤S1305)；进而核心共识节点将包括第一摘要确认事件的第二区块同步至局部共识节点(步骤S1306)。局部共识节点在通过主链同步清分组件(如图12所示的主链同步清分组件327)从第二区块中清分到第一摘要确认事件时，基于归档区块中的所有交易的交易原文确定待备份账本数据(步骤S1307)；进而局部共识节点将待备份账本数据发送给与多层区块链相关联的远程备份设备(步骤S1308)；远程备份设备对待备份账本数据进行备份处理，将备份处理后的待备份账本数据作为账本备份信息(步骤S1309)；接着基于账本备份信息将第一备份签名返回给局部共识节点(步骤S1310)；以及，局部共识节点在接收到第一备份签名后，将第一备份签名发送给核心共识节点(步骤S1311)；核心共识节点在对第一备份签名进行签名验证之后，将账本备份信息与区块数据摘要进行比对(步骤S1312)，并在对比成功时，确定已将待备份账本数据成功备份至远程备份设备。
在本申请实施例中，核心共识节点在确定已将待备份账本数据成功备份至远程备份设备时，还可以生成备份成功信息，进而可以将备份成功信息返回局部共识节点，以使局部共识节点在接收到备份成功信息时，对备份成功的待备份账本数据进行清除，以减少局部共识节点上的存储压力。
本申请实施例提出一种多层区块链数据处理方法。请参见图14，图14是本申请实 施例提供的一种多层区块链数据处理方法的流程示意图。该方法由包括主链清分同步组件的局部共识节点执行。该多层区块链数据处理方法可以包括步骤S401至步骤S404，下面对各步骤分别进行说明。
S401、在从主链上同步到第一区块时，从第一区块中清分局部共识子链的归档任务事件；第一区块中包括与归档任务事件关联的归档配置交易；归档配置交易是由业务对象触发的归档任务命令所确定的；归档任务命令用于对局部共识子链上的局部共识数据进行归档。
可以理解的是，与主链关联的核心共识节点可以接收由业务对象提交的归档配置交易；核心共识节点在验证了归档配置交易的合法性后，将该归档配置交易打包至第一区块，进而核心共识节点可以将第一区块同步至局部共识节点。
可以理解的是，业务对象为包括归档任务命令触发权限的对象(比如，个人或企业账号)，例如，该业务对象可以为基于双层链网络的电子票据系统的管理账号；进而，业务对象可以基于对应的业务设备触发归档任务命令，以对局部共识子链上的局部共识数据进行归档，以及业务对象可以基于归档任务命令确定归档配置交易，并将该归档任务配置交易提交至与主链关联的核心共识节点。
可以理解的是，业务对象在触发归档任务命令时，可以指定待归档的局部共识子链的链标识，即归档任务命令的归档命令参数中可以包含待归档的局部共识子链的链标识；进而局部共识节点能够从归档任务命令所确定的归档配置交易的交易参数中，获得待归档的局部共识子链的链标识，从而局部共识节点可以基于获得的链标识从第一区块中清分到归档配置交易的归档任务事件。通常来说，业务对象可以针对局部共识子链上生成时间距离当前时间一定时间阈值的局部共识数据进行归档，也称为可以对冷数据进行归档。例如，可以对10天之前生成的局部共识区块所对应的账本数据进行归档。
可以理解的是，局部共识节点可以通过主链清分同步组件对主链同步到局部共识节点的主链共识区块(称为第一区块)进行清分，以得到与该局部共识节点所维护的局部共识子链相关联的账本数据和合约数据(也称合约状态)。
可以理解的是，局部共识节点可以基于局部共识子链的链标识，从第一区块中确定出与该局部共识子链相关联的账本数据和合约数据。例如，第一区块中包含归档配置交易，在归档配置交易的交易参数所指示的待归档的局部共识子链的链标识，与局部共识节点所维护的局部共识子链的链标识相同时，则确定该归档配置交易为与局部共识节点所维护的局部共识子链相关联的交易(也称为与局部共识节点相关联的交易)，并基于该归档配置交易生成归档任务事件，也就是相当于从第一区块中清分到与局部共识子链的链标识相匹配的归档任务事件。
S402、在归档任务事件所指示的归档任务命令为账本归档命令时，基于账本归档命令，将局部共识子链上的归档区块的区块数据摘要发送给核心共识节点，核心共识节点用于将区块数据摘要的第一摘要确认事件打包至第二区块，并将第二区块写入主链。
可以理解的是，局部共识节点中可以包括任务触发器，进而在主链清分同步组件清分到与局部共识节点所维护的局部共识子链相匹配的归档任务事件时，任务触发器可以检测清分到的任务事件所对应的类型，若任务触发器检测到任务事件的类型为归档任务事件，且归档任务事件所指示的归档任务命令为局部共识数据对应的账本归档命令时， 则可以根据账本归档命令的指示对局部共识子链上的局部共识数据进行归档。
可以理解的是，账本归档命令用于指示对局部子链上的局部共识区块中的交易原文进行归档，也就是相当于对局部共识区块中的账本数据进行归档。业务对象在触发账本归档命令时，还可以指定局部共识子链上的待归档的局部共识区块的最大区块高度，即账本归档命令的归档命令参数中可以包括待归档的局部共识子链的链标识、以及待归档的局部共识区块的最大区块高度，进而基于账本归档命令所确定的归档配置交易的交易参数中也可以包括待归档的局部共识子链的链标识、以及待归档的局部共识区块的最大区块高度，从而局部共识节点在基于第一区块清分到归档任务事件时，可以从归档任务事件所指示的账本归档命令的归档命令参数中，获得待归档的局部共识区块的最大区块高度。
可以理解的是，局部共识节点还包括局部共识账本数据库；局部共识账本数据库用于存储局部共识子链上的局部共识区块的账本数据，主链子账本数据库还用于存储与局部共识节点相关联的账本数据，存储的账本数据是从同步到的全局共识区块中所清分到的；局部共识节点确定局部共识子链上的归档区块，包括：局部共识节点基于账本归档命令所指示的归档命令参数，确定局部共识子链的待归档区块高度，待归档区块高度为局部共识子链上待进行归档的局部共识区块的最大区块高度；从主链子账本数据库所存储的账本数据中，确定局部共识子链的已归档区块高度；待归档区块高度大于已归档区块高度；获取已归档区块高度与待归档区块高度之间的中间区块高度，将中间区块高度对应的局部共识区块，作为归档区块。
可以理解的是，账本归档命令的归档命令参数中包括待进行归档的局部共识区块的最大区块高度，从而局部共识节点可以将归档命令参数中待进行归档的局部共识区块的最大区块高度作为待归档区块高度。
可以理解的是，局部共识子链上待进行归档的局部共识区块的最大区块高度，为账本归档命令所指示的待进行归档的局部共识区块的最大区块高度的高度值，不同于局部共识子链上未进行归档的局部共识区块的最大区块高度的高度值。例如，局部共识子链上最新的局部共识区块的区块高度的高度值为120，即局部共识子链上未进行归档的局部共识区块的最大区块高度为120，账本归档命令指示对高度值为100之前的局部共识区块进行归档，即局部共识子链上待进行归档的局部共识区块的最大区块高度为100，从而可以确定该局部共识子链中待归档区块高度的高度值为100。
可以理解的是，若主链子账本数据库中存在局部共识子链上已归档的局部共识区块高度，则可以将局部共识子链上的已归档的局部共识区块的区块高度作为已归档区块高度；比如，局部共识子链上的已归档的局部共识区块的区块高度的高度值为n，则表示局部共识子链上区块高度的高度值为0-n(含n)的局部共识区块已归档，即已归档区块高度为n。可以理解的是，已归档区块高度与待归档区块高度之间的区块高度即为中间区块高度，可以不包含已归档区块高度，但包含待归档区块高度。
示例性地，若账本归档命令所指示的归档命令参数包括的待归档区块高度为100，并且在主链子账本数据库中查找到的已归档区块高度为80，则将高度值为80-100之间的局部共识区块(不含80，含100)作为归档区块。
可以理解的是，若在主链子账本数据库中未查找到已归档区块高度，则可以表示当 前未对局部共识子链上的局部共识区块的账本数据进行归档，进而后续可以从局部共识子链的第一个局部共识区块(区块高度为1的局部共识区块)开始进行归档。
在本申请实施例中，局部共识节点基于账本归档命令所指示的归档命令参数确定局部共识子链的待归档区块高度；这里，局部共识节点从主链子账本数据库所存储的账本数据中查找已归档区块高度，若未查找到已归档区块高度，将局部共识子链上的第一个局部共识区块到待归档区块高度所对应的局部共识区块，作为归档区块。
可以理解的是，若未在主链子账本数据库所存储的账本数据中查找到已归档区块高度，则可以将已归档区块高度记为指定值(比如，0)，并将局部共识子链上待归档区块高度之前的所有局部共识区块作为归档区块。
示例性地，若归档命令参数所确定的待归档区块高度为100，且在主链子账本数据库中未查找到已归档的局部共识区块，则表示局部共识子链上的区块未进行归档，进而可以将局部共识子链上的区块高度100之前的100个局部共识区块，作为归档区块。
在本申请实施例中，局部共识节点可以调用局部共识子链上的目标归档业务合约，以基于归档区块的区块数据确定区块数据摘要；接着根据区块数据摘要生成至少一个第一摘要发送交易，并将至少一个第一摘要发送交易发送至核心共识节点，以使核心共识节点基于至少一个第一摘要发送交易生成第一摘要确认事件。
可以理解的是，目标归档业务合约为部署在局部共识子链上的智能合约，且用于进行归档业务处理。可以理解的是，在调用目标归档业务合约确定区块数据摘要时，每个归档区块均可以确定对应的区块数据摘要。可以理解的是，任一归档区块对应的区块数据摘要可以包括归档区块的区块头哈希、区块哈希、交易类型、时间戳等信息，所确定的区块数据摘要用于后续核心共识节点验证归档区块是否成功备份。
可以理解的是，第一摘要发送交易为根据区块数据摘要生成的摘要发送交易，所生成的第一摘要发送交易的数据量根据区块数据摘要的数据量确定。例如，一个第一摘要发送交易可以用于发送区块数据摘要的目标数据量，进而可以将全部归档区块的区块数据摘要按照目标数据量分为至少一份，从而根据每份数据确定一个第一摘要发送交易，并得到与至少一份对应的至少一个第一摘要发送交易。可以理解的是，局部共识节点可以通过任务触发器触发主链转发上链组件将至少一个第一摘要发送交易发送给核心共识节点。
可以理解的是，核心共识节点在接收到全部的第一摘要发送交易后，生成第一摘要确认事件。该第一摘要确认事件用于指示核心共识节点已经接收到局部共识子链上的区块数据摘要。
可以理解的是，核心共识节点在生成第一摘要确认事件时，可以生成第一摘要确认事件关联的第一摘要确认交易，并将第一摘要确认交易打包至第二区块，从而可以将第一摘要确认事件打包至第二区块；最后，核心共识节点将第二区块写入主链。
可以理解的是，第一摘要确认交易的交易参数中携带第一摘要发送交易的局部共识子链的链标识，以使得局部共识节点可以基于该链标识进行数据清分。另外，主链上的第二区块与第一区块为不同全局共识区块，且第一区块的区块高度小于第二区块的区块高度。
S403、从主链上同步第二区块，在从第二区块中清分到第一摘要确认事件时，基于 归档区块中的交易原文确定待备份账本数据，将待备份账本数据发送给与多层链网络的远程备份设备，远程备份设备用于对待备份账本数据进行备份，得到账本备份信息。
可以理解的是，局部共识节点通过主链清分同步组件对第二区块进行清分的方法，与对第一区块的清分方法类似，本申请实施例在此不再重复描述。
可以理解的是，局部共识子链上的局部共识区块的区块体可以包含多个交易，每个交易具有对应的交易原文，也称账本数；局部共识节点可以通过局部共识账本数据库(如图12中的局部共识账本数据库314所示)获得各个局部共识区块中的所有交易的交易原文，也就是说，局部共识账本数据库中存储有归档区块中的所有交易的交易原文，进而可以从局部共识账本数据库中确定归档区块中的所有交易的交易原文；例如，归档区块的区块高度为(80,100]，则从局部共识账本数据库中确定出高度为(80,100]所对应的多个局部共识区块中的所有交易的交易原文。
可以理解的是，局部共识节点基于归档区块中的所有交易的交易原文确定待备份账本数据，可以为将归档区块中的所有交易的交易原文确定为待备份账本数据。这里，也可以为将归档区块中的交易的交易原文、以及归档区块的区块数据摘要确定为待备份账本数据。
可以理解的是，远程备份设备可以用于对局部共识子链上的局部共识数据进行备份。通常来说，远程备份设备可以为一些独立的硬件存储设备，从而可以减少归档数据对于存储资源的浪费。另外，远程备份设备在接收到局部共识节点发送的待备份账本数据后，可以将待备份账本数据进行备份，由此可以实现对归档区块的待备份账本数据的备份，以将局部共识节点上存储的局部共识数据转移至远程备份设备，减少了局部共识节点的存储压力。
在本申请实施例中，在将区块数据摘要发送给核心共识节点后的目标时间段内，若未通过主链清分同步组件清分到第一摘要确认事件，则再次将归档区块的区块数据摘要发送给核心共识节点。
可以理解的是，目标时间段为预设的一个超时重传的时间，若超过该目标时间段未清分到核心共识节点返回的第一摘要确认事件，则重新将区块数据摘要上传至核心共识节点。例如，目标时间段为10分钟，从将区块数据摘要发送给核心共识节点之后开始计时，若达到10分钟局部共识节点仍未通过主链清分同步组件清分到第一摘要确认事件，则再次将归档区块的区块数据摘要发送给核心共识节点。可以理解的是，在归档过程中，局部共识节点在接收到核心共识节点返回的摘要确认事件后，才将归档区块所对应的待归档的账本数据备份至远程备份设备，通过该超时重传机制保障区块数据摘要上传的可靠性，提升归档过程的容错性。
S404、将远程备份设备所发送的第一备份签名转发给核心共识节点，核心共识节点用于在确定第一备份签名由远程备份设备生成、且账本备份信息的账本备份数据摘要与区块数据摘要一致时，确定已将待备份账本数据备份至远程备份设备。
可以理解的是，远程备份设备在将备份处理后的待备份账本数据作为账本备份信息时，可以基于账本备份信息生成第一备份签名。该第一备份签名用于指示远程备份设备已经对待备份账本数据进行备份处理。
可以理解的是，远程备份设备在基于账本备份信息生成第一备份签名时，可以基于 账本备份信息生成第一远程备份确认信息，利用远程备份设备中的私钥对第一远程备份确认信息进行签名处理，得到第一签名信息，并基于第一远程备份确认信息、以及第一签名信息得到第一备份签名。其中，第一远程备份确认信息为基于账本备份信息所确定的账本备份数据摘要，该账本备份数据摘要的确定方法可以与上述区块数据摘要的确定方法一致，以使得核心共识节点可以基于该第一远程备份确认信息与区块数据摘要确定一致性。
可以理解的是，核心共识节点对第一备份签名进行签名验证，可以为通过远程备份设备所对应的公钥对第一备份签名进行验证，从而可以确保局部共识节点上传的第一备份签名是由远程备份设备所生成的，并确保第一备份签名未被篡改。核心共识节点将第一备份签名对应的账本备份信息与区块数据摘要进行比对，可以验证该第一备份签名所指示的账本备份信息已被备份至远程备份设备。
在本申请实施例中，若第一备份签名中的第一远程备份确认信息所对应的账本备份数据摘要，与核心共识节点所接收到的区块数据摘要一致，则表示第一备份签名对应的账本备份信息与区块数据摘要对比成功，进而核心共识节点可以确定已将待备份账本数据备份至远程备份设备。
可以理解的是，核心共识节点可以对接收到的区块数据摘要、以及第一备份签名进行存储，以通过第一备份签名所对应的公钥确定区块数据摘要所对应的局部共识区块所备份的远程备份设备，进而可以从确定的远程备份设备中查找到该区块数据摘要所指示局部共识区块的远程备份账本信息。
可以理解的是，核心共识节点在确定已将待备份账本数据成功备份至远程备份设备时，还可以生成第一备份成功信息，以通知局部共识节点已将待备份账本数据成功备份至远程备份设备。这里，局部共识节点在接收到核心共识节点返回的第一备份成功信息时，将已备份至远程备份设备的待备份账本数据进行清除；第一备份成功信息是核心共识节点在确定已将待备份账本数据成功备份时生成的。
可以理解的是，在将已备份至远程备份设备的待备份账本数据进行清除时，可以将局部共识节点中的待备份账本数据全部进行清除，也可以去除归档区块中的所有交易以及所有交易的交易原文，保留归档区块的区块头数据。
可以理解的是，对局部共识节点中已备份至远程备份设备的待备份账本数据进行清除，相当于将局部共识节点中的一些冷数据转移至远程备份设备上进行存储，从而可以减少局部共识节点上的存储压力。
可以理解的是，局部共识节点可以通过组件清分同步组件对从主链上同步的区块清分到第一备份成功信息，并且可以将该第一备份成功信息存储于主链子账本数据库中。如此，第一备份成功信息中可以包括已备份至远程备份设备的局部共识区块的最大区块高度，进而在下一次清分到用于指示对账本数据进行归档的归档任务事件时，可以从主链子账本数据库所存储的账本数据中查找局部共识子链上已归档的局部共识区块的区块高度，并基于查找到的已归档的局部共识区块的区块高度，进行下一次的区块归档。例如，第一备份成功信息中的已备份至远程备份设备的局部共识区块的最大区块高度为100，则当前局部共识子链上已归档的局部共识区块的区块高度为100。
示例性地，请参见图15，图15是本申请实施例提供的一种账本数据归档过程的流 程示意图。如图15所示，局部共识节点通过主链清分同步组件从主链上同步到第一区块(步骤S501a)，并从第一区块清分到与局部共识节点相关的账本数据和归档任务事件。任务触发器在检测到清分同步组件清分到归档任务事件时，检测归档任务事件的类型，若归档任务事件所指示的归档任务命令为账本归档命令时，任务触发器触发局部链交易执行组件(步骤S502a)，从而使得局部链交易执行组件可以调用对应的目标业务归档合约确定待归档的局部共识区块(也称归档区块)的区块数据摘要。
请参见图16，图16是本申请实施例提供的一种账本数据归档过程的流程示意图。在局部链交易执行组件确定了待归档的局部共识区块的区块数据摘要时，任务触发器触发主链转发上链组件(步骤S501b)，从而使得主链转发上链组件将区块数据摘要发至核心共识网络。其中，当局部共识节点将区块数据摘要发送至核心共识网络时，可以将区块数据摘要放入至少一个第一摘要发送交易中，从而以交易的形式将区块数据摘要发送给核心共识网络。
请参见图17，图17是本申请实施例提供的一种账本数据归档过程的流程示意图。局部共识节点通过主链清分同步组件从主链上同步第二区块(步骤S501c)，并从第二区块中清分与局部共识节点相关的账本数据，以清分到第一摘要确认事件，并在主链清分同步组件清分到第一摘要确认事件时，使得任务触发器触发局部链交易执行组件(步骤S502c)，以使局部链交易执行组件调用对应的目标归档业务合约确定归档任务事件对应的待备份账本数据；进而任务触发器将待备份账本数据发送至远程备份设备(步骤S503c)。远程备份设备在对待备份账本数据进行备份处理后，还可以返回局部共识节点一个第一备份签名。局部共识节点在接收到该第一备份签名时，通过任务触发器触发主链转发上链组件(步骤S504c)，以使主链转发上链组件将第一备份签名上传至核心共识网络。核心共识网络中的核心共识节点基于第一备份签名和区块数据摘要进行一致性比对，在比对成功时，确定待备份账本数据备份成功，进而可以生成第一备份成功信息。
局部共识节点可以接收核心共识网络中的核心共识节点发送的第一备份成功信息，进而对备份成功的待备份账本数据进行清除。这里，第一备份成功信息可以被核心共识节点打包至第四区块，进而局部共识节点可以通过主链清分同步组件从主链上同步到第四区块，并从第四区块清分到与局部共识节点相关的账本数据。局部共识节点在通过任务触发器检测到主链清分同步组件清分到第一备份成功信息时，触发局部链交易执行组件，以使局部链交易执行组件调用对应的目标归档业务合约对备份至远程备份设备的待备份账本数据进行清除。
本申请实施例提出一种多层区块链数据处理方法。请参见图18，图18是本申请实施例提供的一种多层区块链数据处理方法的流程示意图。该方法由局部共识节点执行，包括步骤S601至步骤S604。
S601、在从主链上同步到第一区块时，从第一区块中清分局部共识子链的归档任务事件；第一区块中包括与归档任务事件关联的归档配置交易；归档配置交易是由业务对象触发的归档任务命令所确定的；归档任务命令用于对局部共识子链上的局部共识数据进行归档。
可以理解的是，步骤S601可以参照步骤S401的相关描述，此处不做赘述。
S602、在归档任务事件所指示的归档任务命令为合约归档命令时，基于合约归档命 令，将局部共识子链上的归档合约的合约数据摘要发送给核心共识节点，核心共识节点用于将合约数据摘要对的第二摘要确认事件打包至第三区块，并将第三区块写入主链。
可以理解的是，局部共识节点中的任务触发器触发主链清分同步组件，以清分与该局部共识节点所维护的局部共识子链相匹配的任务事件，任务触发器可以检测清分到的任务事件所对应的类型，若任务触发器检测到任务事件为归档任务事件，且归档任务事件所指示的归档任务命令为局部共识数据对应的合约归档命令时，则根据合约归档命令的指示对局部共识子链上的局部共识数据(如合约的合约数据)进行归档。
可以理解的是，局部共识数据对应的合约归档命令用于指示对局部共识子链上的合约数据进行归档。从而，业务对象在触发合约归档命令时，指定请求归档的局部共识子链的链标识，以及局部共识子链上的待归档合约的合约标识，以及待归档合约的最大合约索引值；因此，合约归档命令的命令参数中包括请求归档的局部共识子链的链标识、局部共识子链上的待归档合约的合约标识、以及待归档合约的最大合约索引值；进而基于合约归档命令所确定的归档配置交易的交易参数包括请求归档的链标识、待归档合约的合约标识、以及待归档合约的最大合约索引值；从而局部共识节点在从包括归档配置交易的第一区块清分到归档任务事件时，可以得到该归档任务事件所指示的合约归档任务命令的归档命令参数，且该归档命令参数包括请求归档的局部共识子链的链标识、局部共识子链上的待归档合约的合约标识、以及待归档合约的最大合约索引值。可以理解的是，合约归档命令中待归档合约的合约标识，可以为合约调用地址、合约标识号或合约名称等，此处不做限制。合约索引值为合约内部的数据顺序索引，如0、1、2、3等序号。
在本申请实施例中，局部共识节点可以基于合约归档命令中的归档命令参数所指示的合约标识，确定局部共识子链上待进行归档的合约，并将局部共识子链上待进行归档的合约作为归档合约。
可以理解的是，主链子账本数据库还用于存储与局部共识节点相关联的合约数据，存储的合约数据是从同步到的全局共识区块中所清分到的；从而，局部共识节点基于合约归档命令，将局部共识子链上归档合约的合约数据摘要发送给核心共识节点，包括：局部共识节点基于合约归档命令所指示的归档命令参数，确定归档合约中的待归档合约索引值，待归档合约索引值为归档合约中待进行归档的最大合约索引值；从主链子账本数据库所存储的账本数据中，查找归档合约中的已归档合约索引值；待归档合约索引值大于已归档合约索引值；基于已归档合约索引值与待归档合约索引值之间的合约索引值，确定局部共识子链上归档合约中的待备份合约数据；将待归档合约数据的合约数据摘要信息发送给核心共识节点。
可以理解的是，在局部共识节点调用合约进行业务处理时，可以更新一次合约的合约状态，该合约状态可以为合约中由键值对表征的合约参数的状态值，并确定该合约状态的合约索引值；在下一次调用合约进行业务处理时，再次更新一次合约状态，并确定更新的合约状态的合约索引值，并且此次所确定的合约索引值比前一次所确定的合约索引值大1。另外，在对合约中的合约数据进行归档时，可以按照合约的合约状态(也称合约数据)的合约索引值进行归档。
可以理解的是，合约归档命令的归档命令参数中包括用于指示局部共识子链上待归 档合约的最大合约索引值，从而可以将待归档合约的最大合约索引值作为待归档合约索引值。可以理解的是，局部共识子链上待归档合约的最大合约索引值为合约归档命令所指示的待归档的最大合约索引值，而不同于局部共识子链上归档合约中未进行归档的最大合约索引值。例如，局部共识子链上当前最大的合约索引值为50，即局部共识子链上归档合约中未进行归档的最大合约索引值为50，合约归档命令指示对合约索引值30之前的合约索引值进行归档，即局部共识子链上归档合约中待归档合约的最大合约索引值为30，从而可以确定待归档合约索引值为30。
可以理解的是，若主链子账本数据库中存在局部共识子链上已归档的合约索引值，则可以将局部共识子链上已归档的合约索引值作为已归档合约索引值；比如，局部共识子链上的已归档合约索引值为n，则表示局部共识子链上归档合约中合约索引值为0-n(含n)的合约数据已归档，即已归档合约索引值为n。可以理解的是，已归档合约索引值与待归档合约索引值之间的合约索引值可以不包含已归档合约索引值，但包含待归档合约索引值；这里，所确定的已归档合约索引值与待归档合约索引值之间的合约索引值，也可以称为归档合约中的归档合约索引值。
示例性地，若合约归档命令所指示的归档命令参数包括的最大合约索引值为50，并且在主链子账本数据库中查找到的已归档合约索引值为40，进而将40-50之间的合约索引值对应的合约数据(不含40，含50)作为归档合约中待归档合约数据。
可以理解的是，若在主链子账本数据库中未查找到局部共识子链上的已归档合约索引值，则表示当前未对局部共识子链上归档合约的合约数据进行归档，进而可以从局部共识子链上归档合约中第一个合约对应的索引值与1的差值(如合约索引值0)开始对归档合约中的合约数据进行归档。
在本申请实施例中，局部共识节点基于合约归档命令所指示的归档命令参数确定归档合约中的待归档合约索引值，待归档合约索引值为归档合约中待归档合约的最大合约索引值；这里，局部共识节点从主链子账本数据库所存储的账本数据中查找已归档合约索引值，若未查找到已归档合约索引值，将局部共识子链上的第一个归档索引值与1的差值到待归档合约索引值之间的合约数据作为待归档合约数据。
可以理解的是，若未在主链子账本数据库所存储的合约数据中查找到已归档合约索引值，则可以将已归档合约索引值记为指定值(比如，0)，从而将局部共识子链上归档合约中待归档合约索引值之前所对应的合约数据均作为待归档合约数据。
示例性地，若合约归档命令所指示的归档命令参数包括的最大合约索引值为50，即待归档合约索引值为50，且在主链子账本数据库中未查找到已归档的局部共识区块的合约索引值，则表示局部共识子链上的区块未进行合约归档，进而可以将0-50之间的合约索引值对应的合约数据作为归档合约中待归档合约数据。
可以理解的是，局部共识节点基于归档合约中待归档合约数据计算，得到合约数据摘要，比如可以对待归档合约数据进行哈希运算，得到合约数据摘要。
在本申请实施例中，局部共识节点可以调用局部共识子链上的目标归档业务合约，以基于归档合约中待归档合约数据确定合约数据摘要；根据合约数据摘要生成至少一个第二摘要发送交易，并将至少一个第二摘要发送交易发送至核心共识节点，以使核心共识节点基于至少一个第二摘要发送交易生成第二摘要确认事件。
可以理解的是，在调用目标归档业务合约确定合约数据摘要时，可以按照一定的计算规则确定待归档合约数据的合约数据摘要；比如可以对待归档合约数据进行哈希运算，得到合约数据摘要，以使核心共识节点验证归档合约中待归档合约数据是否成功备份。
可以理解的是，第二摘要发送交易可以为根据合约数据摘要生成的摘要发送交易，所生成的第二摘要发送交易的数据量可以根据合约数据摘要的数据量进行确定。例如，一个第二摘要发送交易可以用于合约数据摘要的目标数据量，进而可以将合约数据摘要按照目标数据量分为至少一份，从而根据每份数据确定一个第二摘要发送交易，并得到与至少一份对应的至少一个第二摘要发送交易。可以理解的是，局部共识节点可以通过任务触发器触发主链转发上链组件将至少一个第二摘要发送交易发送给核心共识节点。
可以理解的是，核心共识节点在接收到全部的第二摘要发送交易后，生成第二摘要确认事件。该第二摘要确认事件用于指示核心共识节点已经接收到局部共识子链上的区块数据摘要。
可以理解的是，核心共识节点在生成第二摘要确认事件时，可以生成第二摘要确认事件关联的第二摘要确认交易，并将第二摘要确认交易打包至第三区块，从而可以将第二摘要确认事件打包至第三区块；最后，核心共识节点第三区块写入主链。
可以理解的是，第二摘要确认交易的交易参数中携带第二摘要发送交易的局部共识子链的链标识，以使得局部共识节点可以基于该链标识进行数据清分。另外，主链上的第三区块与第一区块可以为不同全局共识区块，且第一区块的区块高度小于第三区块的区块高度。
其中，可以理解的是，在对局部共识子链上的归档合约的合约数据进行归档之前，确定该归档合约在主链中注册了合约名称以及合约索引值，进而业务对象能够触发针对在主链上进行注册合约的合约归档命令。核心共识节点在主链上注册局部共识子链上的合约时，检查待注册合约的描述文件，确认该待注册合约是否实现了归档接口，若该待注册合约没实现归档接口，则核心共识节点后续无法针对局部共识子链上没有实现归档接口的合约进行归档。可以理解的是，核心共识节点触发针对局部共识子链上的合约的归档流程时，每个归档配置交易所指示的归档任务事件只能针对一个合约进行归档，在针对局部子链上的多个合约进行归档的情况下，局部共识节点可以串行执行针对每个合约的合约归档任务。
S603、从主链上同步第三区块，在从第三区块中清分到第二摘要确认事件时，将归档合约中的待备份合约数据发送给远程备份设备，远程备份设备还用于对待备份合约数据进行备份，得到合约备份信息。
可以理解的是，局部共识节点通过主链清分同步组件对第三区块进行清分的方法，与对第一区块进行清分的方法相似方法类似，本申请实施例在此不再重复描述。
可以理解的是，局部共识节点可以通过局部共识账本数据库对局部共识子链上的合约数据进行存储，进而可以从局部共识账本数据库中确定待归档合约数据；例如，归档合约的合约标识为M1，归档合约中的待归档合约数据为合约索引值(30,150]对应的合约数据，进而可以从局部共识账本数据库中确定出合约标识为M1的合约数据中，确定出合约索引值(30,150]所对应的合约数据。
可以理解的是，基于归档合约中待归档合约数据确定待备份合约数据，可以为将归 档合约中的待归档合约数据确定为待备份合约数据。
可以理解的是，远程备份设备在接收到局部共识节点发送的待备份合约数据之后，可以将待备份合约数据进行备份存储，由此可以实现对归档区块对应的待备份合约数据的备份，以将局部共识节点上存储的局部共识数据转移至远程备份设备，减少了局部共识节点的存储压力。
在本申请实施例中，在将合约数据摘要发送给核心共识节点后的目标时间段内，若未通过主链清分同步组件清分到第二摘要确认事件，则再次将归档合约的合约数据摘要发送给核心共识节点。
例如，目标时间段为10分钟，从将合约数据摘要发送给核心共识节点之后开始计时，若达到10分钟局部共识节点仍未通过主链清分同步组件清分得到第二摘要确认事件，则再次将归档区块的区块数据摘要发送给核心共识节点。可以理解的是，在归档过程中，局部共识节点只有在接收到核心共识节点返回的摘要确认事件后，才将待备份合约数据备份至远程备份设备，通过该超时重传机制保障合约数据摘要上传的可靠性，提升归档过程的容错性。
S604、将远程备份设备所发送的第二备份签名转发给核心共识节点，核心共识节点用于在确定第二备份签名由远程备份设备生成、且合约备份信息的账本备份数据摘要与合约数据摘要一致时，确定已将待备份合约数据备份至远程备份设备。
可以理解的是，远程备份设备在将备份处理后的待备份合约数据作为合约备份信息时，可以基于合约备份信息生成第二远程备份签名信息。该第二远程备份签名信息可以用于指示远程备份设备已经对待备份合约数据进行备份处理。
可以理解的是，远程备份设备在基于合约备份信息生成第二备份签名时，可以基于合约备份信息生成第二远程备份确认信息，利用远程备份设备中的私钥对第二远程备份确认信息进行签名处理，得到第二签名信息，并基于第二远程备份确认信息、以及第二签名信息得到第二备份签名。其中，第二远程备份确认信息为基于合约备份信息所确定的合约备份数据摘要，该合约备份数据摘要的确定方法可以与上述合约数据摘要的确定方法一致，以使得核心共识节点可以基于该第二远程备份确认信息与合约数据摘要确定一致性。
可以理解的是，核心共识节点对第二备份签名进行签名验证，可以为通过远程备份设备所对应的公钥对第二备份签名进行验证，从而可以确保局部共识节点上传的第二备份签名是由可信的远程备份设备所生成的，并确保第二备份签名未被篡改。核心共识节点将第二备份签名对应的合约备份信息与合约数据摘要进行比对，可以验证该第二备份签名所指示的合约备份信息已被备份至远程备份设备。
在本申请实施例中，若第二备份签名中的第二远程备份确认信息所对应的合约备份数据摘要，与核心共识节点所接收到的合约数据摘要一致，则表示第二备份签名对应的合约备份信息与合约数据摘要对比成功，进而核心共识节点可以确定已将待备份合约数据备份至远程备份设备。
可以理解的是，核心共识节点可以对接收到的合约数据摘要、以及第二备份签名进行存储，以通过第二备份签名所对应的公钥确定合约数据摘要所对应的合约数据所备份至的远程备份设备，进而可以从确定的远程备份设备中查找到该合约数据摘要所对应的 远程备份合约信息。
可以理解的是，核心共识节点在确定已将待备份合约数据成功备份至远程备份设备时还可以生成第二备份成功信息，以通知局部共识节点已将待备份合约数据成功备份至远程备份设备。这里，局部共识节点在接收到核心共识节点返回的第二备份成功信息时，将已备份至远程备份设备的待备份合约数据进行清除；其中，第二备份成功信息是核心共识节点在确定已将待备份合约数据成功备份至远程备份设备时生成的。
可以理解的是，在将已备份至远程备份设备的待备份合约数据进行清除处理时，可以将局部共识节点中的待备份合约数据全部进行清除。可以理解的是，对局部共识节点中已备份至远程备份设备的待备份合约数据进行清除，也就是相当于将局部共识节点中的一些冷数据转移至远程备份设备上存储，从而可以减少局部共识节点上的存储压力。
示例性地，局部共识节点可以通过主链清分同步组件从主链上同步到第一区块，并清分得到与该局部共识节点相关的账本数据。任务触发器在检测到清分同步组件清分到归档任务事件时，可以对检测归档任务事件的类型进行判断，若判断出归档任务事件所指示的归档任务命令为合约归档命令时，任务触发器触发局部链交易执行组件，以调用对应的目标业务归档合约确定待归档合约的区块数据摘要。接着，任务触发器可以触发主链转发上链组件，从而使得主链转发上链组件可以将合约数据摘要发送给核心共识网络。其中，将合约数据摘要发送至核心共识网络时，可以将合约数据摘要放入至少一个第二摘要发送交易中，从而以交易的形式将合约数据摘要发送给核心共识网络。
局部共识节点可以通过主链清分同步组件从主链上同步到第三区块，在主链清分同步组件从第三区块清分到合约数据摘要对应的摘要确认事件时，任务触发器可以触发局部链交易执行组件，以使局部链交易执行组件可以调用对应的目标归档业务合约确定归档任务事件对应的待备份合约数据，进而任务触发器可以将待备份合约数据发送至远程备份设备。远程备份设备在对待备份合约数据进行备份处理后，还可以返回局部共识节点一个第二备份签名。局部共识节点在接收到该第二备份签名时，可以通过任务触发器触发主链转发上链组件，主链转发上链组件可以将第二备份签名上传至核心共识网络。核心共识网络中的核心共识节点可以基于第二备份签名和合约数据摘要进行一致性比对，在比对成功时，则可以确定待备份合约数据备份成功，进而可以生成第二备份成功信息。
局部共识节点可以接收核心共识节点发送的第二备份成功信息，进而可以基于第二备份成功信息对待备份合约数据进行清除处理。
在本申请实施例中，第二备份成功信息可以被核心共识节点打包至第五区块，进而局部共识节点可以通过主链清分同步组件从主链上同步到第五区块，并从第五区块清分到与局部共识节点相关的账本数据。局部共识节点在通过任务触发器检测到主链清分同步组件清分到上述第二备份成功信息时，任务触发器可以触发局部链交易执行组件，以使局部链交易执行组件调用对应的目标归档业务合约对待备份合约数据进行清除处理。
可以理解的是，局部共识节点可以通过组件清分同步组件对从主链上同步到的区块进行清分，得到第二备份成功信息，并且可以将该第二备份成功信息存储于主链子账本数据库中。该第二备份成功信息中可以包含已备份至远程备份设备的待备份合约数据所对应的合约标识和该合约标识所对应的合约中已备份的最大合约索引值，则该第二备份 成功信息所指示的最大合约索引值就相当于是当前局部共识子链上该第二备份成功信息所指示的合约(如合约标识为M1的合约)中已归档的合约索引值，进而在下一次清分得到针对第二备份成功信息所指示的同一合约的合约数据进行归档的事件时，可以从主链子账本数据库所存储的账本数据中查找局部共识子链上待归档的合约中已归档的合约索引值，并将查找到的局部共识子链上待归档的合约中已归档的合约索引值作为已归档合约索引值。例如，该第二备份成功信息包含的已备份至远程备份设备的待备份合约数据所对应的合约M1的最大合约索引值为100，则当前局部共识子链上合约M1中已归档的合约索引值为100。
在本申请实施例中，局部共识节点在通过主链清分同步组件从第一区块中清分到归档任务事件时，将待归档的局部共识数据对应的摘要(如合约数据摘要)发送至主链对应的核心共识节点；并在通过主链清分同步组件从第二区块中清分到摘要确认事件时，将待归档的局部共识数据(如待备份合约数据)发送至远程备份设备进行备份；然后局部共识节点在接收到远程备份设备返回的第二备份签名时，将第二备份签名发送至核心共识节点，以使核心共识节点在对摘要与第二远程备份签名比对成功时，确定已对待归档的局部共识数据备份至远程备份设备。由此可以通过主链对应的核心共识节点接收归档配置交易，进而控制用于进行区域性业务处理的局部共识子链上的局部共识数据的归档，从而可以对不同区域内的业务节点相关的交易分别进行归档，由此通过多层区块链之间的协作归档，提升对区块链的数据归档过程的可控性以及数据归档时的安全性。并且，在数据归档过程中，核心共识节点可以对局部共识数据的归档过程进行审核，提升局部共识数据的归档过程的可控性以及数据安全性。
本申请实施例在通过核心共识节点将由业务对象针对归档任务命令所提交的归档配置交易打包至第一区块，且上链至主链的情况下，可以确保部署在多层区块链的局部共识网络中的局部共识节点，从该核心共识节点所维护的主链上同步到该打包有归档配置交易的第一区块，进而从该第一区块中清分到该归档任务命令相关联的归档任务事件，进而可以获取到该归档任务事件所指示的归档任务命令。因此，本申请实施例可以通过多层区块链之间的相互协作，控制局部共识节点根据当前获取到的归档任务命令对自己本地的局部共识数据(例如，局部共识节点自己本地所存储的合约状态数据)进行归档，以实现对局部共识子链上的局部共识数据进行数据归档时的可控性。另外，由于局部共识节点在将自己本地的合约数据备份至远程备份设备之前，是将自己本地所存储的合约数据的摘要通过核心共识节点上链至主链，而并非是直接将自己本地所存储的合约数据通过核心共识节点上链至主链，进而可以确保该局部共识节点自己本地所执行合约数据并不会被其他业务节点所同步到，从而可以在对该局部共识子链上的局部共识数据进行数据归档时，确保该局部共识节点上所执行的交易的隐私性和安全性。另外，在数据归档过程中，核心共识节点还可以一并对由局部共识节点所提交的摘要和第二备份签名进行对比，进而可以在对局部共识子链上的局部共识数据的归档过程中，确保备份在远程备份设备上的账本备份信息的数据安全性。
本申请实施例提出一种多层区块链数据处理方法。请参见图19，图19是本申请实施例提供的一种多层区块链数据处理方法的流程示意图。该方法由核心共识节点执行，该多层区块链数据处理方法包括步骤S801至步骤S804，下面对各步骤分别进行说明。
S801、将第一区块同步至与局部共识子链的局部共识节点，局部共识节点用于从第一区块中清分局部共识子链的归档任务事件；第一区块中包括与归档任务事件关联的归档配置交易；归档配置交易是由业务对象触发的归档任务命令所确定的；归档任务命令用于对局部共识子链上的局部共识数据进行归档。
S802、接收局部共识节点发送的归档区块的区块数据摘要，将区块数据摘要的第一摘要确认事件打包至第二区块，将第二区块写入主链；归档区块为在归档任务事件所指示的归档任务命令为账本归档命令时，由局部共识节点基于账本归档命令确定的局部共识子链上待归档的局部共识区块。
S803、将第二区块同步至局部共识节点，局部共识节点还用于从第二区块中清分到第一摘要确认事件时确定待备份账本数据，并将待备份账本数据发送给与多层链网络的远程备份设备。
S804、接收局部共识节点返回的第一备份签名，在确定第一备份签名由远程备份设备生成、且账本备份信息的账本备份数据摘要与区块数据摘要一致时，确定已将待备份账本数据成功备份至远程备份设备；第一备份签名为远程备份设备基于账本备份信息返回的信息，且第一备份签名是通过局部共识节点转发的，账本备份信息为远程备份设备对待备份账本数据进行备份所得到的信息。
需要说明的是，由于步骤S801至步骤S804所对应的描述，与步骤S601至步骤S604所对应的描述相对，本申请实施例在此不再重复描述。
请参见图20，图20是本申请实施例提供的一种区块链数据处理装置的结构示意图。如图20所示，第一区块链数据处理装置20-1可应用于局部共识节点中，该局部共识节点可以为局部共识网络(例如，上述局部共识网络100a)中任意一个区块链节点。应当理解，该第一区块链数据处理装置20-1可以是运行于区块链节点中的一个计算机程序(包括程序代码)，例如该第一区块链数据处理装置20-1可以为一个应用软件；可以理解的是，该第一区块链数据处理装置20-1可以用于执行本申请实施例提供的应用于局部共识节点的区块链数据处理方法中的相应步骤。如图20所示，第一区块链数据处理装置20-1可以包括：打包模块20-11、共识模块20-12和处理模块20-13；
打包模块20-11，配置为将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，所述局部共识交易是指在所述局部共识网络中执行的业务交易，所述主链绑定高度为第一全局共识区块的区块高度，所述第一全局共识区块是在打包所述局部共识交易时从所述核心共识节点的主链上同步到的，所述主链读数据集合是从第一全局合约状态中所清分到的、且用于执行所述局部共识交易，所述第一全局合约状态为在执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
共识模块20-12，配置为将所述局部共识区块广播给局部验证节点，所述局部验证节点用于在所同步到的区块高度大于或等于所述主链绑定高度、以及所同步到的读数据集合与所述主链读数据集合一致时，获取所述局部共识交易的交易执行结果所对应的投票共识结果，所述局部验证节点为所述局部共识网络中除所述局部共识节点之外的共识节点；
处理模块20-13，配置为在基于所述局部验证节点返回的投票共识结果确定达成共识时，将所述局部共识区块上链至所述局部共识网络对应的局部共识子链，并将所述局 部共识区块写入局部共识账本数据库。
其中，共识模块20-12还包括：数据审核单元20-121和区块共识单元20-122。
其中，数据审核单元20-121包括：
合约调用子单元20-1211，配置为调用所述局部共识子链上的局部共识业务合约执行数据审核；
数据查找子单元20-1213，配置为从主链子账本数据库中获取待确认区块高度；所述待确认区块高度为通过所述核心共识节点从所述主链上同步到的第二全局共识区块的区块高度，所述第二全局共识区块为对所述局部共识区块共识时同步到的所述主链上的全局共识区块；在所述待确认区块高度大于或等于所述主链绑定高度时，在所述主链子账本数据库中查找与所述第一全局共识区块相关联的读数据集合，得到待确认读数据集合；
数据对比子单元20-1214，配置为将所述待确认读数据集合中的键值对作为第一键值对，并将所述主链读数据集合的键值对作为第二键值对，在所述第一键值对和所述第二键值对一致时，执行所述局部共识区块中的所述局部共识交易，得到交易执行结果。
区块共识单元20-122，配置为在所述待确认区块高度低于所述主链绑定高度时，取消对所述主链读数据集合的审核；
区块共识单元20-122，还配置为在所述第一键值对与所述第二键值对不一致时，取消执行所述局部共识交易。
其中，打包模块20-11还包括：
同步请求生成单元20-111，配置为调用主链清分同步组件生成主链清分同步请求；主链清分同步请求携带第一全局共识区块的区块高度；
同步请求发送单元20-112，配置为将所述主链清分同步请求发送给所述核心共识节点；所述主链清分同步请求用于指示所述核心共识节点将高于所述第一全局共识区块的区块高度的全局共识区块，确定为所述主链上未同步给所述局部共识节点的全局共识区块，并从未同步给所述局部共识节点的全局共识区块中，选取待同步全局区块；
数据接收单元20-113，配置为接收所述核心共识节点返回的所述待同步全局区块，并将所述待同步全局区块作为所述第二全局共识区块。
其中，打包模块20-11还包括：
绑定高度确定单元20-114，配置为在打包所述局部共识交易时，通过所述核心共识节点从所述主链上获取最大全局区块高度、以及所述最大全局区块高度对应的全局共识区块；将所述最大全局区块高度对应的全局共识区块作为所述第一全局共识区块，并将所述最大全局区块高度作为所述主链绑定高度。
其中，处理模块20-13还包括：
同步请求获取单元20-131，配置为获取局部业务节点发送的子链清分同步请求；所述局部业务节点包括局部链子账本数据库，所述子链清分同步请求携带所述局部业务节点从局部共识子链上同步到的局部区块高度，所述局部共识子链为所述局部共识节点的区块链，所述局部区块高度为局部共识区块的区块高度；
局部区块选取单元20-132，配置为将所述局部共识子链上区块高度大于所述局部区块高度的局部共识区块，确定为未同步给所述局部业务节点的局部共识区块，并从所述 未同步给所述局部业务节点的局部共识区块中，选取待同步局部区块；
局部区块发送单元20-133，配置为获取所述待同步局部区块的局部合约状态，并将所述待同步局部区块和所述局部合约状态返回给所述局部业务节点，所述局部业务节点用于将所述待同步局部区块、以及所述局部合约状态写入所述局部链子账本数据库中；所述局部合约状态为执行所述待同步局部区块中的局部共识交易所读取到的读数据集合，所述局部共识交易由所述局部共识网络的局部共识子链上的局部共识业务合约执行。
其中，局部区块选取单元20-132，还配置为当所述局部共识子链上的最大局部区块高度等于或小于所述局部区块高度时，从所述局部共识子链上获取最大局部区块高度对应的局部共识区块；将所述最大局部区块高度对应的局部共识区块作为所述待同步局部区块。
其中，数据接收单元20-113，还配置为从所述主链上同步包括注册交易的目标共识区块，所述注册交易是指向所述核心共识节点申请注册所述局部共识子链的业务交易，所述目标共识区块中写有所述注册交易对应的配置交易，所述配置交易携带有配置信息；
打包模块20-11还包括：
区块创建子单元20-115，配置为从所述目标共识区块中获取所述配置信息，在所述配置信息与所述局部共识节点所配置的信息一致时，在所述局部共识网络中创建创世区块；基于所述创世区块启动所述局部共识子链。
处理模块20-13，还配置为对所述局部共识交易对应的执行结果进行交易汇总处理，得到汇总交易信息；生成携带所述汇总交易信息的信息上链交易；调用主链转发上链组件生成携带所述信息上链交易的主链上链请求；将所述主链上链请求发送给所述核心共识节点，所述主链上链请求用于指示所述核心共识节点将携带所述信息上链交易写入所述主链。
继续参见图20，第一区块链数据处理装置20-1还包括：主链同步模块20-81、归档数据处理模块20-82、数据备份模块20-83、信息接收模块20-84；
主链同步模块20-81，配置为在从所述主链上同步到第一区块时，从所述第一区块中清分所述局部共识子链的归档任务事件；所述第一区块中包括与所述归档任务事件关联的归档配置交易；所述归档配置交易是由业务对象触发的归档任务命令所确定的；所述归档任务命令用于对所述局部共识子链上的局部共识数据进行归档；
归档数据处理模块20-82，配置为在所述归档任务事件所指示的所述归档任务命令为账本归档命令时，基于所述账本归档命令，将所述局部共识子链上的归档区块的区块数据摘要发送给所述核心共识节点，所述核心共识节点用于将所述区块数据摘要的第一摘要确认事件打包至第二区块，并将所述第二区块写入所述主链；
数据备份模块20-83，配置为从所述主链上同步所述第二区块，在从所述第二区块中清分到所述第一摘要确认事件时，基于所述归档区块中的交易原文确定待备份账本数据，将所述待备份账本数据发送给与所述多层链网络的远程备份设备，所述远程备份设备用于对所述待备份账本数据进行备份，得到账本备份信息；
信息接收模块20-84，配置为将所述远程备份设备所发送的第一备份签名转发给所述核心共识节点，所述核心共识节点用于在确定所述第一备份签名由所述远程备份设备生成、且所述账本备份信息的账本备份数据摘要与所述区块数据摘要一致时，确定已将 所述待备份账本数据备份至所述远程备份设备。
其中，局部共识节点包括局部共识账本数据库和主链子账本数据库；所述局部共识账本数据库用于存储所述局部共识子链上的局部共识区块的账本数据，所述主链子账本数据库用于存储与所述局部共识节点相关联的账本数据，存储的所述账本数据是从同步到的全局共识区块中清分到的；
归档数据处理模块20-82，包括：命令解析单元20-821、数据查找单元20-822、备份数据确定单元20-823；
命令解析单元20-821，配置为从所述账本归档命令所指示的归档命令参数中，读取所述局部共识子链的待归档区块高度，所述待归档区块高度为所述局部共识子链上待归档局部共识区块的最大区块高度；
数据查找单元20-822，配置为从所述主链子账本数据库所存储的账本数据中，确定所述局部共识子链的已归档区块高度；所述待归档区块高度大于所述已归档区块高度；
备份数据确定单元20-823，配置为获取所述已归档区块高度与所述待归档区块高度之间的中间区块高度，将所述中间区块高度对应的局部共识区块，作为所述归档区块。
其中，归档数据处理模块20-82，包括：合约调用单元20-824、信息发送单元20-825；
合约调用单元20-824，配置为调用所述局部共识子链上的目标归档业务合约对所述归档区块的区块数据进行处理，得到所述区块数据摘要；
信息发送单元20-825，配置为根据所述区块数据摘要生成至少一个第一摘要发送交易；将至少一个所述第一摘要发送交易发送至所述核心共识节点，所述核心共识节点用于基于至少一个所述第一摘要发送交易生成所述第一摘要确认事件。
其中，第一区块链数据处理装置20-1还包括数据清除模块20-85；数据清除模块20-85，配置为在接收到所述核心共识节点返回的第一备份成功信息时，将已备份至所述远程备份设备的所述待备份账本数据进行清除；所述第一备份成功信息是所述核心共识节点在确定已将所述待备份账本数据成功备份时生成的。
其中，所述归档数据处理模块20-82，还配置为在所述归档任务事件所指示的所述归档任务命令为合约归档命令时，基于所述合约归档命令，将所述局部共识子链上的归档合约的合约数据摘要发送给所述核心共识节点，所述核心共识节点用于将所述合约数据摘要对的第二摘要确认事件打包至第三区块，并将所述第三区块写入所述主链；
所述数据备份模块20-83，还配置为从所述主链上同步所述第三区块，在从所述第三区块中清分到所述第二摘要确认事件时，将所述归档合约中的待备份合约数据发送给所述远程备份设备，所述远程备份设备还用于对所述待备份合约数据进行备份，得到合约备份信息；
所述信息接收模块20-84，还配置为将所述远程备份设备所发送的第二备份签名转发给所述核心共识节点，所述核心共识节点用于在确定所述第二备份签名由所述远程备份设备生成、且所述合约备份信息的账本备份数据摘要与所述合约数据摘要一致时，确定已将所述待备份合约数据备份至所述远程备份设备。
其中，所述归档数据处理模块20-82，还配置为基于所述合约归档命令中的归档命令参数所指示的合约标识，从所述局部共识子链上确定所述归档合约。
其中，主链子账本数据库还用于存储与所述局部共识节点相关联的合约数据，存储 的所述合约数据是从同步到的全局共识区块中所清分到的；
所述命令解析单元20-821，还配置为从所述归档命令参数中，读取所述归档合约中的待归档合约索引值，所述待归档合约索引值为所述归档合约中待进行归档的最大合约索引值；
数据查找单元20-822，还配置为从所述主链子账本数据库所存储的账本数据中，查找所述归档合约中的已归档合约索引值；所述待归档合约索引值大于所述已归档合约索引值；
备份数据确定单元20-823，还配置为基于所述已归档合约索引值与所述待归档合约索引值之间的合约索引值，确定所述局部共识子链上的所述归档合约中的待备份合约数据。
其中，合约调用单元20-824，还配置为调用所述局部共识子链上的目标归档业务合约对所述归档合约的所述待备份合约数据进行处理，得到所述合约数据摘要；
信息发送单元20-825，还配置为根据所述合约数据摘要生成至少一个第二摘要发送交易；将所述至少一个第二摘要发送交易发送至所述核心共识节点，所述核心共识节点用于基于所述至少一个第二摘要发送交易生成所述第二摘要确认事件。
其中，信息发送单元20-825，还配置为在接收到所述核心共识节点返回的第二备份成功信息时，将已备份至所述远程备份设备的所述待备份合约数据进行清除；所述第二备份成功信息是所述核心共识节点在确定已将所述待备份合约数据成功备份时生成的。
其中，打包模块20-11、共识模块20-12、处理模块20-13、主链同步模块20-81、归档数据处理模块20-82、数据备份模块20-83和信息接收模块20-84的实现方式，可以参见上述描述，这里将不再继续进行赘述。另外，对于采用相同方法所得到的相同有益效果的描述，也不再进行赘述。
请参见图21，图21是本申请实施例提供的一种区块链数据处理装置的结构示意图。如图21所示，第二区块链数据处理装置21-1可应用于核心共识节点中。应当理解，该第二区块链数据处理装置21-1可以是运行于区块链节点中的一个计算机程序(包括程序代码)，例如该第二区块链数据处理装置21-1可以为一个应用软件；可以理解的是，该第二区块链数据处理装置21-1可以用于执行本申请实施例提供的方法中的相应步骤。如图21所示，第二区块链数据处理装置21-1可以包括：获取模块21-21，确定模块21-22、数据返回模块21-23；
获取模块21-21，配置为获取局部共识节点发送的主链同步请求，所述主链同步请求携带第三全局共识区块的区块高度；所述第三全局共识区块为所述局部共识节点在同步到第一全局共识区块之前从主链上同步到的全局共识区块；
确定模块21-22，配置为从所述主链上，将区块高度大于所述第三全局共识区块的区块高度的全局共识区块，确定为未同步给所述局部共识节点的第一全局共识区块；
获取模块21-21，还配置为从所述主链上获取所述第一全局共识区块的第一全局合约状态；所述第一全局合约状态为执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
数据返回模块21-23，配置为将所述第一全局共识区块、以及所述第一全局合约状态返回给所述局部共识节点，所述局部共识节点用于基于第一全局共识区块的区块高度 和第一全局合约状态，将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，并在基于所述局部共识网络对所述局部共识区块达成共识时，将所述局部共识区块上链至所述局部共识网络中。
其中，获取模块21-21，确定模块21-22和数据返回模块21-23的实现方式，可以参见上述描述，这里将不再继续进行赘述。另外，对于采用相同方法所得到的相同有益效果的描述，也不再进行赘述。
继续参见参见图21，第二区块链数据处理装置21-1还包括：数据同步模块21-91、信息确认模块21-92和信息验证模块21-93；
数据同步模块21-91，配置为将第一区块同步至与局部共识子链的局部共识节点，所述局部共识节点用于从所述第一区块中清分所述局部共识子链的归档任务事件；所述第一区块中包括与所述归档任务事件关联的归档配置交易；所述归档配置交易是由业务对象触发的归档任务命令所确定的；所述归档任务命令用于对所述局部共识子链上的局部共识数据进行归档；
信息确认模块21-92，配置为接收所述局部共识节点发送的归档区块的区块数据摘要，将所述区块数据摘要的第一摘要确认事件打包至第二区块，将所述第二区块写入所述主链；所述归档区块为在所述归档任务事件所指示的所述归档任务命令为账本归档命令时，由所述局部共识节点基于所述账本归档命令确定的所述局部共识子链上待归档的局部共识区块；
所述数据同步模块21-91，配置为将所述第二区块同步至所述局部共识节点，所述局部共识节点还用于从所述第二区块中清分到所述第一摘要确认事件时确定待备份账本数据，并将所述待备份账本数据发送给与所述多层链网络的远程备份设备；
信息验证模块21-93，配置为接收所述局部共识节点返回的第一备份签名，在确定所述第一备份签名由所述远程备份设备生成、且账本备份信息的账本备份数据摘要与所述区块数据摘要一致时，确定已将所述待备份账本数据成功备份至所述远程备份设备；所述第一备份签名为所述远程备份设备基于所述账本备份信息返回的信息，且所述第一备份签名是通过所述局部共识节点转发的，所述账本备份信息为所述远程备份设备对所述待备份账本数据进行备份所得到的信息。
请参见图22，图22是本申请实施例提供的一种电子设备的结构示意图。如图22所示，该电子设备1200可以为终端，还可以为服务器，这里将不对其进行限制。可以理解的是，电子设备可以为局部共识节点以及核心共识节点。为便于理解，本申请实施例以电子设备为服务器为例进行说明，该电子设备1200可以包括：处理器1201，网络接口1204和存储器1205，此外，该电子设备1200还可以包括：用户接口1203，和至少一个通信总线1202。其中，通信总线1202用于实现这些组件之间的连接通信。其中，用户接口1203还可以包括标准的有线接口、无线接口。网络接口1204可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1205可以是高速随机存储器(Random Access Memory，RAM)存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1205可选的还可以是至少一个位于远离前述处理器1201的存储装置。如图22所示，作为一种计算机可读存储介质的存储器1205中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
其中，该电子设备1200中的网络接口1204还可以提供网络通讯功能。在图22所示的电子设备1200中，网络接口1204可提供网络通讯功能；而用户接口1203主要用于为用户提供输入的接口；而处理器1201可以用于调用存储器1205中存储的设备控制应用程序，以执行本申请实施例提供的应用于局部共识节点的区块链数据处理方法或应用于核心共识节点的区块链数据处理方法。
本申请实施例还提供了一种计算机可读存储介质，且计算机可读存储介质中存储有第一区块链数据处理装置或者第二区块链数据处理装置所执行的计算机程序，且计算机程序包括计算机指令，当处理器执行计算机指令时，能够执行本申请实施例提供的应用于局部共识节点的区块链数据处理方法或应用于核心共识节点的区块链数据处理方法。作为示例，计算机指令可被部署在一个电子设备上执行，或者在位于一个地点的多个电子设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个电子设备上执行，分布在多个地点且通过通信网络互连的多个电子设备可以组成区块链系统。
本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或者计算机程序可以包括计算机指令，该计算机指令可以存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器可以执行该计算机指令，使得该电子设备执行本申请实施例提供的应用于局部共识节点的区块链数据处理方法或应用于核心共识节点的区块链数据处理方法。
请参见图23，图23是本申请实施例提供的一种区块链数据处理系统的示意图。该区块链数据处理系统23-3可以包含局部共识节点3a和核心共识节点3b；其中，局部共识节点3a可以为本申请实施例所描述的处于局部共识网络中的局部共识节点。其中，核心共识节点3b可以为本申请实施例所描述的处于核心共识网络中的核心共识节点。
需要说明的是，对于前述的各个步骤，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某一些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储器(Read-Only Memory，ROM)或RAM等。
以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (26)

  1. 一种区块链数据处理方法，所述方法由局部共识网络中的局部共识节点执行，所述局部共识网络部署在多层链网络的业务网络中，所述多层链网络中还部署有独立于所述业务网络的核心共识网络，所述核心共识网络包括核心共识节点；所述方法包括：
    将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，所述局部共识交易是指在所述局部共识网络中执行的业务交易，所述主链绑定高度为第一全局共识区块的区块高度，所述第一全局共识区块是在打包所述局部共识交易时从所述核心共识节点的主链上同步到的，所述主链读数据集合是从第一全局合约状态中所清分到的、且用于执行所述局部共识交易，所述第一全局合约状态为在执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
    将所述局部共识区块广播给局部验证节点，所述局部验证节点用于在所同步到的区块高度大于或等于所述主链绑定高度、以及所同步到的读数据集合与所述主链读数据集合一致时，获取所述局部共识交易的交易执行结果所对应的投票共识结果，所述局部验证节点为所述局部共识网络中除所述局部共识节点之外的共识节点；
    在基于所述局部验证节点返回的投票共识结果确定达成共识时，将所述局部共识区块上链至所述局部共识网络对应的局部共识子链，并将所述局部共识区块写入局部共识账本数据库。
  2. 根据权利要求1所述的方法，其中，所述方法还包括：
    调用所述局部共识子链上的局部共识业务合约执行以下处理：
    从主链子账本数据库中获取待确认区块高度；所述待确认区块高度为通过所述核心共识节点从所述主链上同步到的第二全局共识区块的区块高度，所述第二全局共识区块为对所述局部共识区块共识时同步到的所述主链上的全局共识区块；
    在所述待确认区块高度大于或等于所述主链绑定高度时，在所述主链子账本数据库中查找与所述第一全局共识区块相关联的读数据集合，得到待确认读数据集合；
    将所述待确认读数据集合中的键值对作为第一键值对，并将所述主链读数据集合的键值对作为第二键值对，在所述第一键值对和所述第二键值对一致时，执行所述局部共识区块中的所述局部共识交易，得到交易执行结果。
  3. 根据权利要求2所述的方法，其中，所述从主链子账本数据库中获取待确认区块高度之后，所述方法还包括：
    在所述待确认区块高度低于所述主链绑定高度时，取消对所述主链读数据集合的审核。
  4. 根据权利要求2所述的方法，其中，所述将所述待确认读数据集合中的键值对作为第一键值对，并将所述主链读数据集合的键值对作为第二键值对之后，所述方法还包括：
    在所述第一键值对与所述第二键值对不一致时，取消执行所述局部共识交易。
  5. 根据权利要求2所述的方法，其中，所述方法还包括：
    调用主链清分同步组件生成主链清分同步请求；所述主链清分同步请求携带所述第一全局共识区块的区块高度；
    将所述主链清分同步请求发送给所述核心共识节点；所述主链清分同步请求用于指示所述核心共识节点将高于所述第一全局共识区块的区块高度的全局共识区块，确定为所述主链上未同步给所述局部共识节点的全局共识区块，并从未同步给所述局部共识节点的全局共识区块中，选取待同步全局区块；
    接收所述核心共识节点返回的所述待同步全局区块，并将所述待同步全局区块作为所述第二全局共识区块。
  6. 根据权利要求1所述的方法，其中，所述方法还包括：
    在打包所述局部共识交易时，通过所述核心共识节点从所述主链上获取最大全局区块高度、以及所述最大全局区块高度对应的全局共识区块；
    将所述最大全局区块高度对应的全局共识区块作为所述第一全局共识区块，并将所述最大全局区块高度作为所述主链绑定高度。
  7. 根据权利要求1至6任一项所述的方法，其中，所述方法还包括：
    获取局部业务节点发送的子链清分同步请求；所述局部业务节点包括局部链子账本数据库，所述子链清分同步请求携带所述局部业务节点从局部共识子链上同步到的局部区块高度，所述局部共识子链为所述局部共识节点的区块链，所述局部区块高度为局部共识区块的区块高度；
    将所述局部共识子链上区块高度大于所述局部区块高度的局部共识区块，确定为未同步给所述局部业务节点的局部共识区块，并从所述未同步给所述局部业务节点的局部共识区块中，选取待同步局部区块；
    获取所述待同步局部区块的局部合约状态，并将所述待同步局部区块和所述局部合约状态返回给所述局部业务节点，所述局部业务节点用于将所述待同步局部区块、以及所述局部合约状态写入所述局部链子账本数据库中；所述局部合约状态为执行所述待同步局部区块中的局部共识交易所读取到的读数据集合，所述局部共识交易由所述局部共识网络的局部共识子链上的局部共识业务合约执行。
  8. 根据权利要求7所述的方法，其中，所述获取局部业务节点发送的子链清分同步请求之后，所述方法还包括：
    当所述局部共识子链上的最大局部区块高度等于或小于所述局部区块高度时，从所述局部共识子链上获取最大局部区块高度对应的局部共识区块；
    将所述最大局部区块高度对应的局部共识区块作为所述待同步局部区块。
  9. 根据权利要求1至6任一项所述的方法，其中，所述方法还包括：
    从所述主链上同步包括注册交易的目标共识区块，所述注册交易是指向所述核心共识节点申请注册所述局部共识子链的业务交易，所述目标共识区块中写有所述注册交易对应的配置交易，所述配置交易携带有配置信息；
    从所述目标共识区块中获取所述配置信息，在所述配置信息与所述局部共识节点所配置的信息一致时，在所述局部共识网络中创建创世区块；
    基于所述创世区块启动所述局部共识子链。
  10. 根据权利要求2至6任一项所述的方法，其中，所述方法还包括：
    对所述局部共识交易对应的执行结果进行交易汇总处理，得到汇总交易信息；
    生成携带所述汇总交易信息的信息上链交易；
    调用主链转发上链组件生成携带所述信息上链交易的主链上链请求；
    将所述主链上链请求发送给所述核心共识节点，所述主链上链请求用于指示所述核心共识节点将携带所述信息上链交易写入所述主链。
  11. 根据权利要求1至6任一项所述的方法，其中，所述方法还包括：
    在从所述主链上同步到第一区块时，从所述第一区块中清分所述局部共识子链的归档任务事件；所述第一区块中包括与所述归档任务事件关联的归档配置交易；所述归档配置交易是由业务对象触发的归档任务命令所确定的；所述归档任务命令用于对所述局部共识子链上的局部共识数据进行归档；
    在所述归档任务事件所指示的所述归档任务命令为账本归档命令时，基于所述账本归档命令，将所述局部共识子链上的归档区块的区块数据摘要发送给所述核心共识节点，所述核心共识节点用于将所述区块数据摘要的第一摘要确认事件打包至第二区块，并将所述第二区块写入所述主链；
    从所述主链上同步所述第二区块，在从所述第二区块中清分到所述第一摘要确认事件时，基于所述归档区块中的交易原文确定待备份账本数据，将所述待备份账本数据发送给与所述多层链网络的远程备份设备，所述远程备份设备用于对所述待备份账本数据进行备份，得到账本备份信息；
    将所述远程备份设备所发送的第一备份签名转发给所述核心共识节点，所述核心共识节点用于在确定所述第一备份签名由所述远程备份设备生成、且所述账本备份信息的账本备份数据摘要与所述区块数据摘要一致时，确定已将所述待备份账本数据备份至所述远程备份设备。
  12. 根据权利要求11所述方法，其中，所述局部共识节点包括局部共识账本数据库和主链子账本数据库；所述局部共识账本数据库用于存储所述局部共识子链上的局部共识区块的账本数据，所述主链子账本数据库用于存储与所述局部共识节点相关联的账本数据，存储的所述账本数据是从同步到的全局共识区块中清分到的；所述基于所述账本归档命令，将所述局部共识子链上的归档区块的区块数据摘要发送给所述核心共识节点，包括：
    从所述账本归档命令所指示的归档命令参数中，读取所述局部共识子链的待归档区块高度，所述待归档区块高度为所述局部共识子链上待归档局部共识区块的最大区块高度；
    从所述主链子账本数据库所存储的账本数据中，确定所述局部共识子链的已归档区块高度；所述待归档区块高度大于所述已归档区块高度；
    获取所述已归档区块高度与所述待归档区块高度之间的中间区块高度，将所述中间区块高度对应的局部共识区块，作为所述归档区块；
    将所述归档区块的所述区块数据摘要发送给所述核心共识节点。
  13. 根据权利要求11所述方法，其中，所述将所述局部共识子链上的归档区块的区块数据摘要发送给所述核心共识节点，包括：
    调用所述局部共识子链上的目标归档业务合约对所述归档区块的区块数据进行处理，得到所述区块数据摘要；
    根据所述区块数据摘要生成至少一个第一摘要发送交易；
    将至少一个所述第一摘要发送交易发送至所述核心共识节点，所述核心共识节点用于基于至少一个所述第一摘要发送交易生成所述第一摘要确认事件。
  14. 根据权利要求11所述方法，其中，所述将所述远程备份设备所发送的第一备份签名转发给所述核心共识节点之后，所述方法还包括：
    在接收到所述核心共识节点返回的第一备份成功信息时，将已备份至所述远程备份设备的所述待备份账本数据进行清除；所述第一备份成功信息是所述核心共识节点在确定已将所述待备份账本数据成功备份时生成的。
  15. 根据权利要求11所述方法，其中，所述从所述第一区块中清分所述局部共识子链的归档任务事件之后，所述方法还包括：
    在所述归档任务事件所指示的所述归档任务命令为合约归档命令时，基于所述合约归档命令，将所述局部共识子链上的归档合约的合约数据摘要发送给所述核心共识节点，所述核心共识节点用于将所述合约数据摘要对的第二摘要确认事件打包至第三区块，并将所述第三区块写入所述主链；
    从所述主链上同步所述第三区块，在从所述第三区块中清分到所述第二摘要确认事件时，将所述归档合约中的待备份合约数据发送给所述远程备份设备，所述远程备份设备还用于对所述待备份合约数据进行备份，得到合约备份信息；
    将所述远程备份设备所发送的第二备份签名转发给所述核心共识节点，所述核心共识节点用于在确定所述第二备份签名由所述远程备份设备生成、且所述合约备份信息的账本备份数据摘要与所述合约数据摘要一致时，确定已将所述待备份合约数据备份至所述远程备份设备。
  16. 根据权利要求15所述方法，其中，所述基于所述合约归档命令，将所述局部共识子链上的归档合约的合约数据摘要发送给所述核心共识节点，包括：
    基于所述合约归档命令中的归档命令参数所指示的合约标识，从所述局部共识子链上确定所述归档合约；
    将所述归档合约的所述合约数据摘要发送给所述核心共识节点。
  17. 根据权利要求16所述方法，其中，主链子账本数据库还用于存储与所述局部共识节点相关联的合约数据，存储的所述合约数据是从同步到的全局共识区块中所清分到的；所述将所述归档合约的所述合约数据摘要发送给所述核心共识节点，包括：
    从所述归档命令参数中，读取所述归档合约中的待归档合约索引值，所述待归档合约索引值为所述归档合约中待进行归档的最大合约索引值；
    从所述主链子账本数据库所存储的账本数据中，查找所述归档合约中的已归档合约索引值；所述待归档合约索引值大于所述已归档合约索引值；
    基于所述已归档合约索引值与所述待归档合约索引值之间的合约索引值，确定所述局部共识子链上的所述归档合约中的待备份合约数据；
    将所述待备份合约数据的所述合约数据摘要发送给所述核心共识节点。
  18. 根据权利要求15所述方法，其中，所述将所述局部共识子链上的归档合约的合约数据摘要发送给所述核心共识节点，包括：
    调用所述局部共识子链上的目标归档业务合约对所述归档合约的所述待备份合约数据进行处理，得到所述合约数据摘要；
    根据所述合约数据摘要生成至少一个第二摘要发送交易；
    将至少一个所述第二摘要发送交易发送至所述核心共识节点，所述核心共识节点用于基于至少一个所述第二摘要发送交易生成所述第二摘要确认事件。
  19. 根据权利要求15所述方法，其中，所述将所述远程备份设备所发送的第二备份签名转发给所述核心共识节点之后，所述方法还包括：
    在接收到所述核心共识节点返回的第二备份成功信息时，将已备份至所述远程备份设备的所述待备份合约数据进行清除；所述第二备份成功信息是所述核心共识节点在确定已将所述待备份合约数据成功备份时生成的。
  20. 一种区块链数据处理方法，所述方法由核心共识网络中的核心共识节点执行，所述核心共识网络部署在多层链网络中，所述多层链网络中与所述核心共识网络独立的业务网络部署有局部共识网络，所述局部共识网络包括局部共识节点，所述方法包括：
    获取所述局部共识节点发送的主链同步请求，所述主链同步请求携带第三全局共识区块的区块高度；所述第三全局共识区块为所述局部共识节点在同步到第一全局共识区块之前从主链上同步到的全局共识区块；
    从所述主链上，将区块高度大于所述第三全局共识区块的区块高度的全局共识区块，确定为未同步给所述局部共识节点的第一全局共识区块；
    从所述主链上获取所述第一全局共识区块的第一全局合约状态；所述第一全局合约状态为执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
    将所述第一全局共识区块、以及所述第一全局合约状态返回给所述局部共识节点，所述局部共识节点用于基于第一全局共识区块的区块高度和第一全局合约状态，将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，并在基于所述局部共识网络对所述局部共识区块达成共识时，将所述局部共识区块上链至所述局部共识网络中。
  21. 根据权利要求20所述的方法，其中，所述方法还包括：
    将第一区块同步至与局部共识子链的局部共识节点，所述局部共识节点用于从所述第一区块中清分所述局部共识子链的归档任务事件；所述第一区块中包括与所述归档任务事件关联的归档配置交易；所述归档配置交易是由业务对象触发的归档任务命令所确定的；所述归档任务命令用于对所述局部共识子链上的局部共识数据进行归档；
    接收所述局部共识节点发送的归档区块的区块数据摘要，将所述区块数据摘要的第一摘要确认事件打包至第二区块，将所述第二区块写入所述主链；所述归档区块为在所述归档任务事件所指示的所述归档任务命令为账本归档命令时，由所述局部共识节点基于所述账本归档命令确定的所述局部共识子链上待归档的局部共识区块；
    将所述第二区块同步至所述局部共识节点，所述局部共识节点还用于从所述第二区块中清分到所述第一摘要确认事件时确定待备份账本数据，并将所述待备份账本数据发送给与所述多层链网络的远程备份设备；
    接收所述局部共识节点返回的第一备份签名，在确定所述第一备份签名由所述远程备份设备生成、且账本备份信息的账本备份数据摘要与所述区块数据摘要一致时，确定已将所述待备份账本数据成功备份至所述远程备份设备；所述第一备份签名为所述远程备份设备基于所述账本备份信息返回的信息，且所述第一备份签名是通过所述局部共识 节点转发的，所述账本备份信息为所述远程备份设备对所述待备份账本数据进行备份所得到的信息。
  22. 一种第一区块链数据处理装置，所述第一区块链数据处理装置运行在局部共识网络中的局部共识节点上，所述局部共识网络部署在多层链网络的业务网络中，所述多层链网络中还部署有独立于所述业务网络的核心共识网络，所述核心共识网络包括核心共识节点，所述第一区块链数据处理装置包括：
    打包模块，配置为将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，所述局部共识交易是指在所述局部共识网络中执行的业务交易，所述主链绑定高度为第一全局共识区块的区块高度，所述第一全局共识区块是在打包所述局部共识交易时从所述核心共识节点的主链上同步到的，所述主链读数据集合是从第一全局合约状态中所清分到的、且用于执行所述局部共识交易，所述第一全局合约状态为在执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
    共识模块，配置为将所述局部共识区块广播给局部验证节点，所述局部验证节点用于在所同步到的区块高度大于或等于所述主链绑定高度、以及所同步到的读数据集合与所述主链读数据集合一致时，获取所述局部共识交易的交易执行结果所对应的投票共识结果，所述局部验证节点为所述局部共识网络中除所述局部共识节点之外的共识节点；
    处理模块，配置为在基于所述局部验证节点返回的投票共识结果确定达成共识时，将所述局部共识区块上链至所述局部共识网络对应的局部共识子链，并将所述局部共识区块写入局部共识账本数据库。
  23. 一种第二区块链数据处理装置，所述第二区块链数据处理装置运行在核心共识网络中的核心共识节点上，所述核心共识网络部署在多层链网络中；所述多层链网络中的业务网络部署有局部共识网络，所述局部共识网络是通过独立与所述业务网络的核心共识网络中的核心共识节点所构建的；所述第二区块链数据处理装置包括：
    获取模块，配置为获取局部共识节点发送的主链同步请求，所述主链同步请求携带第三全局共识区块的区块高度；所述第三全局共识区块为所述局部共识节点在同步到第一全局共识区块之前从主链上同步到的全局共识区块；
    确定模块，配置为从所述主链上，将区块高度大于所述第三全局共识区块的区块高度的全局共识区块，确定为未同步给所述局部共识节点的第一全局共识区块；
    所述获取模块，还配置为从所述主链上获取所述第一全局共识区块的第一全局合约状态；所述第一全局合约状态为执行所述第一全局共识区块中的全局共识交易时所读取到的读数据集合；
    数据返回模块，配置为将所述第一全局共识区块、以及所述第一全局合约状态返回给所述局部共识节点，所述局部共识节点用于基于第一全局共识区块的区块高度和第一全局合约状态，将局部共识交易、主链绑定高度和主链读数据集合打包为局部共识区块，并在基于所述局部共识网络对所述局部共识区块达成共识时，将所述局部共识区块上链至所述局部共识网络中。
  24. 一种用于区块链数据处理的电子设备，所述电子设备包括存储器和处理器；
    所述存储器与所述处理器相连，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以使得电子设备执行权利要求1至21任一项所述的方法。
  25. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行，以使得电子设备执行权利要求1至21任一项所述的方法。
  26. 一种计算机程序产品，所述计算机程序产品包括计算机程序或计算机可执行指令，所述计算机程序或计算机可执行指令被处理器执行时，实现权利要求1至21任一项所述的方法。
PCT/CN2023/114284 2022-12-15 2023-08-22 一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品 Ceased WO2024124952A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP23902161.1A EP4568174A4 (en) 2022-12-15 2023-08-22 BLOCKCHAIN DATA PROCESSING METHOD, APPARATUS, DEVICE, COMPUTER-READABLE STORAGE MEDIA AND COMPUTER PROGRAM PRODUCT
US18/510,310 US12445316B2 (en) 2022-12-15 2023-11-15 Blockchain data processing method, apparatus, and device, computer-readable storage medium, and computer program product

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202211637944.0A CN118210853A (zh) 2022-12-15 2022-12-15 多层区块链数据处理方法、相关设备、介质及程序产品
CN202211637945.5 2022-12-15
CN202211637944.0 2022-12-15
CN202211637945.5A CN118214569A (zh) 2022-12-15 2022-12-15 区块链数据处理方法、装置、设备、介质及产品

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/510,310 Continuation US12445316B2 (en) 2022-12-15 2023-11-15 Blockchain data processing method, apparatus, and device, computer-readable storage medium, and computer program product

Publications (1)

Publication Number Publication Date
WO2024124952A1 true WO2024124952A1 (zh) 2024-06-20

Family

ID=91484339

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/114284 Ceased WO2024124952A1 (zh) 2022-12-15 2023-08-22 一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品

Country Status (1)

Country Link
WO (1) WO2024124952A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN121125742A (zh) * 2025-11-14 2025-12-12 北京致医健康信息技术有限公司 一种基于数据分析的数据多向同步方法及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190332702A1 (en) * 2018-04-30 2019-10-31 Hewlett Packard Enterprise Development Lp System and method of decentralized management of multi-owner nodes using blockchain
CN110601857A (zh) * 2019-09-25 2019-12-20 东北大学 一种基于局部-全局区块链协同的数据交互方法
US20200366495A1 (en) * 2018-01-29 2020-11-19 Ubiquicorp Limited Proof of majority block consensus method for generating and uploading a block to a blockchain
CN112541758A (zh) * 2020-12-01 2021-03-23 鲁静 基于区块链的多轮投票式容错排序共识机制与方法
CN113067707A (zh) * 2021-06-02 2021-07-02 腾讯科技（深圳）有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质
CN114511319A (zh) * 2021-12-29 2022-05-17 壹链盟生态科技有限公司 一种区块链共识方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200366495A1 (en) * 2018-01-29 2020-11-19 Ubiquicorp Limited Proof of majority block consensus method for generating and uploading a block to a blockchain
US20190332702A1 (en) * 2018-04-30 2019-10-31 Hewlett Packard Enterprise Development Lp System and method of decentralized management of multi-owner nodes using blockchain
CN110601857A (zh) * 2019-09-25 2019-12-20 东北大学 一种基于局部-全局区块链协同的数据交互方法
CN112541758A (zh) * 2020-12-01 2021-03-23 鲁静 基于区块链的多轮投票式容错排序共识机制与方法
CN113067707A (zh) * 2021-06-02 2021-07-02 腾讯科技（深圳）有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质
CN114511319A (zh) * 2021-12-29 2022-05-17 壹链盟生态科技有限公司 一种区块链共识方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN121125742A (zh) * 2025-11-14 2025-12-12 北京致医健康信息技术有限公司 一种基于数据分析的数据多向同步方法及系统

Similar Documents

Publication Publication Date Title
US20230316273A1 (en) Data processing method and apparatus, computer device, and storage medium
CN108777625B (zh) 签名的验证方法、装置和系统、存储介质、电子装置
EP4332870A1 (en) Transaction data processing method and apparatus, computer device and storage medium
EP4568174A1 (en) Blockchain data processing method, apparatus, device, computer-readable storage medium, and computer program product
CN120494970B (zh) 基于区块链的数字资产安全交易系统及方法
CN117917681B (zh) 基于多区块链的资产转移方法、装置、设备、介质及产品
CN119691819A (zh) 用于管理区块链网络上的大区块的计算机实现的系统和方法
CN112615847B (zh) 基于区块链的数据共享和隐私保护方法
CN109766673A (zh) 一种联盟式音视频版权区块链系统及音视频版权上链方法
US20230289782A1 (en) Smart contract-based data processing
WO2024082818A1 (zh) 基于多区块链的跨链处理方法、装置、设备、系统及介质
CN116708463B (zh) 基于多区块链的信息处理方法、装置、设备以及介质
WO2024093593A1 (zh) 基于多区块链的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品
WO2024099023A1 (zh) 多区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品
CN116827957B (zh) 基于多区块链的信息处理方法、装置、设备以及介质
WO2024124952A1 (zh) 一种区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品
CN113300853A (zh) 金融征信信息管理方法、装置、电子设备及存储介质
CN115695449A (zh) 一种区块链数字藏品源文件跨平台同步与转移方法
CN117938867A (zh) 一种多区块链数据处理方法、装置、设备、介质及产品
CN117951217B (zh) 基于多区块链的跨链配置方法、装置、设备、系统及介质
WO2024153001A1 (zh) 一种基于分层链网络的数据处理方法、装置、设备及介质
CN118214569A (zh) 区块链数据处理方法、装置、设备、介质及产品
CN118210853A (zh) 多层区块链数据处理方法、相关设备、介质及程序产品
CN117992534B (zh) 基于多区块链的数据跨链方法、相关设备、介质及产品
WO2024216966A1 (zh) 基于分层链的数据处理方法、装置、设备及介质

Legal Events

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

Ref document number: 23902161

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 11202500398T

Country of ref document: SG

WWP Wipo information: published in national office

Ref document number: 11202500398T

Country of ref document: SG

WWE Wipo information: entry into national phase

Ref document number: 2023902161

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2023902161

Country of ref document: EP

Effective date: 20250304

WWP Wipo information: published in national office

Ref document number: 2023902161

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE