WO2021213065A1 - 一种区块链数据归档方法、装置和计算机可读存储介质 - Google Patents

一种区块链数据归档方法、装置和计算机可读存储介质 Download PDF

Info

Publication number
WO2021213065A1
WO2021213065A1 PCT/CN2021/080371 CN2021080371W WO2021213065A1 WO 2021213065 A1 WO2021213065 A1 WO 2021213065A1 CN 2021080371 W CN2021080371 W CN 2021080371W WO 2021213065 A1 WO2021213065 A1 WO 2021213065A1
Authority
WO
WIPO (PCT)
Prior art keywords
accounting node
state data
data
node
information
Prior art date
Application number
PCT/CN2021/080371
Other languages
English (en)
French (fr)
Inventor
吴小龙
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to JP2022539416A priority Critical patent/JP7330596B2/ja
Publication of WO2021213065A1 publication Critical patent/WO2021213065A1/zh
Priority to US17/703,085 priority patent/US20220214995A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/113—Details of archiving
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/178—Techniques for file synchronisation in file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Definitions

  • This application relates to the field of communication technology, and in particular to a blockchain data archiving method, device, electronic equipment, and computer-readable storage medium.
  • Blockchain system refers to the collection of a series of nodes that incorporate new blocks into the blockchain through consensus.
  • the application of blockchain systems in the transaction field has become more and more. Extensive, for example, it can be used in transaction scenarios such as banks and governments.
  • the storage space occupied by the blockchain data of each node in the blockchain system will also increase, resulting in slow response or even downtime of the nodes in the blockchain system. Circumstances have a negative impact on the operation of the blockchain.
  • the embodiment of the application provides a blockchain data archiving method, which is used in a blockchain system.
  • the blockchain system includes a consensus node, a first accounting node, and a second accounting node, and the method includes:
  • the first accounting node synchronizes blockchain data with the consensus node, and determines the synchronization block height of the synchronized blockchain data, and the synchronized blockchain data includes state data;
  • the first accounting node determines the target state data required by the current transaction in the state data, and backs up the target state data
  • the first accounting node generates a state data snapshot of the synchronization block height according to the backed up target state data, and snapshots the state data, the synchronization block height, and the signature information of the first accounting node Together as archive point information, and sent to the second accounting node;
  • the first accounting node archives the synchronized blockchain data according to the endorsement information and the archive point information.
  • an embodiment of the present application provides a blockchain data archiving device for use in a blockchain system.
  • the blockchain system includes a consensus node, a first accounting node, and a second accounting node.
  • the device includes :
  • a synchronization unit configured to synchronize the blockchain data between the first accounting node and the consensus node, and determine the synchronization block height of the synchronized blockchain data, and the synchronized blockchain data includes state data;
  • a determining unit configured to determine the target state data required by the current transaction in the state data by the first accounting node, and back up the target state data
  • the generating unit is configured so that the first accounting node generates a state data snapshot of the synchronization block height according to the target state data after the backup, and combines the state data snapshot, the synchronization block height, and the first record
  • the signature information of the accounting nodes is collectively used as archive point information and sent to the second accounting node;
  • a receiving unit configured to receive the endorsement information of the second accounting node for the archive point information by the first accounting node
  • the archiving unit is configured so that the first accounting node archives the synchronized blockchain data according to the endorsement information and the archiving point information.
  • an embodiment of the present application also provides an electronic device, including a processor and a memory, the memory stores executable instructions, and the processor is configured to execute the executable instructions stored in the memory to implement the embodiments of the present application.
  • an electronic device including a processor and a memory, the memory stores executable instructions, and the processor is configured to execute the executable instructions stored in the memory to implement the embodiments of the present application.
  • an embodiment of the present application also provides a computer-readable storage medium that stores executable instructions, which are used to implement the blockchain data archiving provided by the embodiments of the present application when executed by a processor. method.
  • Fig. 1A is a schematic structural diagram of a blockchain data archiving system provided by an embodiment of the present application
  • FIG. 1B is a schematic structural diagram of a blockchain system provided by an embodiment of the present application.
  • FIG. 2A is a schematic flowchart of a blockchain data archiving method provided by an embodiment of the present application
  • 2B is a schematic flowchart of a blockchain data archiving method provided by an embodiment of the present application.
  • 2C is a schematic flowchart of a blockchain data archiving method provided by an embodiment of the present application.
  • FIG. 3 is a schematic diagram of sub-state data backup provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a snapshot of the Merkel tree corresponding to the state data provided by an embodiment of the present application
  • FIG. 5 is a schematic diagram of blockchain data archiving of the first accounting node provided by an embodiment of the present application.
  • Fig. 6 is a schematic diagram of a process of archiving blockchain data in a blockchain system provided by an embodiment of the present application
  • FIG. 7 is a schematic structural diagram of a Merkel tree corresponding to state data provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a process of constructing a local world state by a first accounting node according to an embodiment of the present application
  • FIG. 9 is a schematic flowchart of a blockchain data archiving method provided by an embodiment of the present application.
  • FIG. 10 is a schematic diagram of the flow of obtaining the latest blockchain data by the first accounting node according to an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of a blockchain data archiving device provided by an embodiment of the present application.
  • FIG. 12 is a schematic structural diagram of a blockchain data archiving device provided by an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of a blockchain data archiving device provided by an embodiment of the present application.
  • FIG. 14 is a schematic structural diagram of a blockchain data archiving device provided by an embodiment of the present application.
  • FIG. 15 is a schematic structural diagram of a blockchain data archiving device provided by an embodiment of the present application.
  • FIG. 16 is a schematic structural diagram of an electronic device provided by an embodiment of the present application.
  • first ⁇ second ⁇ third involved only distinguishes similar objects, and does not represent a specific order for the objects. Understandably, “first ⁇ second ⁇ third” Where permitted, the specific order or sequence can be interchanged, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein.
  • the term “plurality” refers to at least two.
  • Blockchain It is an encrypted, chain-type transaction storage structure formed by blocks.
  • the header of each block can not only include the hash value of all transactions in the block, but also the hash value of all transactions in the previous block, so as to achieve tamper-proof transactions in the block based on the hash value And anti-counterfeiting; newly generated transactions are filled in the block and after the consensus of the nodes in the block chain system, they will be appended to the end of the block chain to form chain growth.
  • Blockchain Network Also known as the blockchain system, it refers to a series of nodes that incorporate new blocks into the blockchain through consensus.
  • Transaction equivalent to the computer term "transaction”, a transaction includes operations that need to be submitted to the blockchain system for execution, and does not simply refer to transactions in a business context.
  • transaction the embodiments of this application follow this habit.
  • the deployment (Deploy) transaction is used to install the specified smart contract on the node in the blockchain system and is ready to be called;
  • the Invoke transaction is used to add the transaction record in the blockchain by calling the smart contract, and
  • Operations on the state database of the blockchain include update operations (including adding, deleting, and modifying key-value pairs in the state database) and query operations (ie, querying the key-value pairs in the state database).
  • Ledger a collective term for blockchain (also known as ledger data) and a state database synchronized with the blockchain.
  • the blockchain records transactions in the form of files in the file system
  • the state database records transactions in the blockchain in the form of key (Key) value (Value) pairs, and is used to support transactions in the blockchain.
  • the state database is also called the ledger database.
  • Smart contracts also known as chain code (Chaincode) or application code, the program deployed in the node of the blockchain network, the node executes the smart contract called in the received transaction, to check the state database The key value updates or queries the data.
  • Consensus It is a process in the blockchain system used to reach agreement on transactions in the block between multiple nodes involved, and the agreed block will be appended to the end of the blockchain .
  • the mechanisms for achieving consensus include proof of work (PoW, Proof of Work), proof of equity (PoS, Proof of Stake), and share authorization proof (DPoS, Delegated Proof-of-Stake), etc.
  • the applicant of this application found that the blockchain system is still providing transaction services normally when generating a snapshot of the ledger. If the state data of the accounting node is read and written in the snapshot, it still exists Transaction, snapshot reading and writing will conflict with the transaction, resulting in snapshot reading failure or inaccurate data read by the snapshot, and the generated state data snapshot also lacks credibility. Therefore, in the solutions provided by related technologies, the archiving accuracy and archiving efficiency of blockchain data are low.
  • the embodiments of the present application provide a blockchain data archiving method, device, electronic equipment, and computer-readable storage medium, which can effectively improve the archiving accuracy and archiving efficiency of blockchain data.
  • the blockchain data archiving device can be integrated in an electronic device, and the electronic device can be a server or a terminal or other equipment.
  • the blockchain data archiving method provided in the embodiments of the present application is mainly applied to the blockchain system, which is a new application mode of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • the blockchain is essentially a decentralized database, which is a series of data blocks associated with cryptographic methods. Each data block contains a batch of network transaction information to verify the validity of the information. (Anti-counterfeiting) and generate the next block.
  • the blockchain can include the underlying platform of the blockchain, the platform product service layer, and the application service layer.
  • the underlying platform of the blockchain can include processing modules such as user management, basic services, smart contracts, and operation monitoring.
  • the user management module is responsible for the identity information management of all blockchain participants, including the maintenance of public and private key generation (account management), key management, and maintenance of the correspondence between the user’s real identity and the blockchain address (authority management), etc.
  • authorization supervise and audit certain real-identity transactions, and provide risk control rule configuration (risk control audit); basic service modules are deployed on all blockchain node devices to verify the validity of business requests, After completing the consensus on the valid request, it is recorded on the storage.
  • the basic service For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management), After encryption, it is completely and consistently transmitted to the shared ledger (network communication), and recorded and stored; the smart contract module is responsible for contract registration and issuance, contract triggering and contract execution.
  • interface adaptation interface adaptation
  • consensus algorithm consensus algorithm
  • the smart contract module is responsible for contract registration and issuance, contract triggering and contract execution.
  • the operation monitoring module is mainly responsible for the deployment of the product release process , Configuration modification, contract settings, cloud adaptation, and visual output of real-time status during product operation, such as: alarms, monitoring network conditions, monitoring node equipment health status, etc.
  • the platform product service layer provides basic capabilities and implementation frameworks for typical applications. Based on these basic capabilities, developers can superimpose business characteristics to complete the blockchain implementation of business logic.
  • the application service layer provides application services based on the blockchain solution for business participants to use.
  • FIG. 1A is a schematic structural diagram of the blockchain data archiving system 100 provided by the embodiment of the present application, including a blockchain system 200 (block The chain system 200 includes a plurality of nodes, the node 210 is exemplarily shown in FIG. 1A) and the service system 400 (the terminal 410 belonging to the service system 400 and the graphical interface 420 thereof are exemplarily shown), which will be described separately below.
  • the type of the blockchain system 200 is flexible and diverse, for example, it can be any one of a public chain, a private chain, or a consortium chain.
  • the electronic equipment of any business system (or business subject), such as terminals and servers can access the blockchain system 200 without authorization; taking the alliance chain as an example, the business system is getting After authorization, electronic devices (such as terminals/servers) under its jurisdiction can access the blockchain system 200. At this time, they become a special type of node in the blockchain system 200, namely, the client node.
  • the blockchain system 200 receives the transaction submitted by the client node of the business system (for ease of description, the terminal 410 is taken as an example below), executes the transaction to update the ledger or query the ledger, and displays the execution in the graphical interface 420 of the terminal 410 Various intermediate or final results of the transaction. Understandably, for the blockchain system 200 that receives and executes transactions above, it specifically refers to the native node 210 in the blockchain system 200.
  • the client node of the business system has a blockchain system When the functions of the native node 210 in 200 (for example, consensus function, accounting function), the corresponding client node may also be included.
  • the following takes the business system access to the blockchain system as an example to illustrate an exemplary application of the blockchain system.
  • the terminal 410 when the terminal 410 needs to upload data to the blockchain, it can generate a transaction corresponding to the update operation, and the transaction includes the data that needs to be uploaded.
  • the transaction can also specify the smart contract that needs to be called to implement the update operation and the parameters passed to the smart contract.
  • the transaction can also carry the digital signature signed by the business system 400 (for example, the digital certificate issued by the certification center 300 for the business system 400)
  • the private key in the transaction is obtained by encrypting the digest of the transaction), and the transaction is broadcast to the blockchain system 200.
  • the node 210 in the blockchain system 200 receives the transaction, it verifies the digital signature carried by the transaction.
  • the node 210 successfully verifies the digital signature in the transaction, it confirms whether the business system 400 has the transaction authority according to the identity of the business system 400 carried in the transaction. Any verification judgment of the digital signature and authority verification will cause the transaction to fail.
  • the digital signature of the node 210 is signed (for example, the digest of the transaction is encrypted using the private key of the node 210), and it continues to be broadcast in the blockchain system 200.
  • the digital signature is the signature information.
  • the node 210 with the sorting function in the blockchain system 200 After the node 210 with the sorting function in the blockchain system 200 receives the successfully verified transaction, it fills the transaction into a new block and broadcasts it to the node (ie, consensus node) that provides the consensus service in the blockchain system 200.
  • the node ie, consensus node
  • the node 210 that provides consensus services in the blockchain system 200 performs a consensus process on the new block to reach a consensus.
  • the node 210 that provides the accounting function (ie, the accounting node) appends the new block to the end of the blockchain and executes the new block.
  • Transactions in blocks For transactions that submit data, add key-value pairs corresponding to the data in the state database to update the state database. It is worth noting that a node in the blockchain system can provide multiple functions at the same time, for example, it provides sorting function and consensus function at the same time.
  • the terminal 410 when the terminal 410 needs to query data from the blockchain system 200, it can generate a transaction corresponding to the query operation (for example, the transaction may include the key to be queried), specify the smart contract that needs to be called to implement the query operation, and For the parameters passed to the smart contract, the transaction can also carry the digital signature signed by the business system 400 and broadcast the transaction to the blockchain system 200.
  • the transaction may include the key to be queried
  • the smart contract For the parameters passed to the smart contract, the transaction can also carry the digital signature signed by the business system 400 and broadcast the transaction to the blockchain system 200.
  • the block is filled and the consensus is consistent, the new block is appended to the end of the blockchain, and the transaction in the new block is executed: for the transaction querying data, query from the state database Corresponding key-value pairs, and return the query result (for example, the query result can be the value corresponding to the key in the submitted transaction).
  • the blockchain system may include a consensus node and multiple accounting nodes.
  • the accounting node can be responsible for implementing the read and write operations on the ledger by executing the chain code, that is, it is mainly responsible for maintaining the state data and a copy of the ledger.
  • the accounting node can also be called a peer node.
  • Consensus nodes can also be called consensus ordering nodes (Orderer).
  • they are mainly used to receive transactions containing signature information, sort unpackaged transactions to generate blocks, and broadcast to peer nodes and blockchain systems.
  • the number of consensus nodes included may be only one, and of course the blockchain system may also include a node cluster of consensus nodes.
  • the accounting node that needs to perform the archiving operation is called the first accounting node, and the other accounting nodes are called the second accounting node.
  • the number of second accounting nodes Is at least one.
  • the blockchain system 500 includes a first accounting node 510, a second accounting node 520, and a consensus node 530.
  • the first accounting node 510 may synchronize the blockchain data with the consensus node 530, and determine the synchronization block height of the synchronized blockchain data, and the synchronized blockchain data includes state data. Then, the first accounting node 510 determines the target state data required for the current transaction in the state data, and backs up the target state data, where the current transaction is a transaction performed after the blockchain data is synchronized.
  • the first accounting node 510 generates a state data snapshot of the synchronization block height according to the target state data after the backup, and uses the state data snapshot, the synchronization block height, and the signature information of the first accounting node 510 as archive point information together, and The archive point information is sent to the second accounting node 520.
  • the first accounting node 510 receives the endorsement information of the second accounting node 520 for the archive point information, and the endorsement information is used to instruct the second accounting node 520 to approve the archive point information.
  • the first accounting node 510 archives the synchronized blockchain data according to the endorsement information and archiving point information.
  • the block chain data can include block data in the block chain and state data describing the world state (World State).
  • the block data is the record of each transaction that actually occurs on the block chain.
  • the data can include normal block data and configuration block data.
  • the state data may include recording the current state of each account and smart contract, and the state data of the node may be stored in the state database (ie, the local database) of the node.
  • archiving can be understood as data archiving, which mainly refers to copying some data in the blockchain data to obtain a snapshot, and can also refer to deleting and/or transferring block data within a certain range to other distributed In the cold storage of the storage system (referring to the distributed storage system different from the blockchain system, dedicated to archiving), to save the local storage space of the accounting node.
  • the nodes in the blockchain system may be servers or terminals, and client nodes are the same.
  • the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or it can provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, and cloud communications. , Middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), and cloud servers for basic cloud computing services such as big data and artificial intelligence platforms.
  • the terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc., but it is not limited to this.
  • the terminal and the server can be directly or indirectly connected through wired or wireless communication, which is not limited in the embodiment of the present application.
  • the embodiments of the present application will be described from the perspective of a blockchain data archiving device.
  • the blockchain data archiving device may be integrated in an electronic device, and the electronic device may be a server or a terminal and other equipment.
  • FIG. 2A is a schematic flowchart of a blockchain data archiving method provided by an embodiment of the present application, which will be described in conjunction with the steps shown in FIG. 2A.
  • step 101 the first accounting node synchronizes the blockchain data with the consensus node, and determines the synchronization block height of the synchronized blockchain data, and the synchronized blockchain data includes state data.
  • the blockchain system includes a consensus node and multiple accounting nodes.
  • the accounting node can also be called a Peer node, which is responsible for implementing the read and write operations on the ledger by executing the chain code, that is, it is mainly responsible for maintaining the state data and the copy of the ledger.
  • the consensus node is used to receive transactions containing signature information, sort unpackaged transactions to generate blocks, and broadcast to Peer nodes.
  • the accounting node that needs to archive data is referred to as the first accounting node, and other accounting nodes are referred to as the second accounting node, and the number of the second accounting nodes is at least one.
  • the first accounting node When the first accounting node needs to archive data, it first synchronizes the blockchain data with the consensus node, and determines the synchronization block height of the blockchain data after synchronization.
  • the synchronized blockchain data includes block data and status data.
  • the block data is used to describe the blocks in the blockchain.
  • the status data can include recording the current status of each account and smart contract in the blockchain system. .
  • the synchronization block height may refer to the block height (or the number of blocks) of the synchronized block chain data obtained after the first accounting node and the consensus node synchronize the block chain data. For example, if there are 5 blocks in the blockchain data after the synchronization of the first accounting node, the synchronization block height can be 5.
  • the above-mentioned first accounting node and consensus node can synchronize blockchain data in this way: the first accounting node sends a synchronization request to the consensus node, and the synchronization request includes the first accounting node
  • the first billing node receives the block sent by the consensus node for the synchronization request; where the block is sent when the consensus node verifies the identity of the first billing node in the synchronization request; the first note
  • the account node updates the local blockchain data according to the block sent by the consensus node, and obtains the synchronized blockchain data.
  • the first accounting node may send a synchronization request to the consensus node, and the synchronization request may carry the identity of the first accounting node.
  • the consensus node receives the synchronization request, it verifies the identity of the first accounting node in the synchronization request.
  • the consensus node passes the verification of the identity of the first accounting node, that is, when it is determined that there is no problem with the identity of the first accounting node, the block locally stored by the consensus node is sent to the first accounting node.
  • the consensus node can send all the blocks stored locally to the first accounting node, or send the latest block to the first accounting node to save computing resources, where the latest block can refer to the latest Blocks that are appended to the end of the blockchain and whose number is equal to the synchronization number threshold (such as 1 or 2) can also refer to the last synchronization (that is, the consensus node sends the block to the first accounting node once) Based on the new block.
  • the consensus node sending the latest block to the first accounting node as an example.
  • the first accounting node After the first accounting node receives the latest block from the consensus node, it updates the local blockchain data according to the latest block received, and uses the updated blockchain data as the synchronized blockchain data , Complete the blockchain data synchronization.
  • the first accounting node recognizes the number of blocks existing in the synchronized blockchain data, and uses the number of blocks as the synchronized block height of the synchronized blockchain data. For example, if the synchronized blockchain data contains 5 blocks, the synchronized block height of the synchronized blockchain data is 5.
  • the first accounting node may trigger a synchronization request (send a synchronization request to the consensus node) when receiving an archiving request or an archiving instruction (for example, an artificially triggered archiving request or an archiving instruction).
  • the first billing node can also automatically trigger the sending of synchronization requests every fixed time period. For example, the first billing node can be set to trigger a synchronization request every 5 minutes or every 20 minutes and other time periods, and then Determine the synchronization block height of the blockchain data after synchronization.
  • step 102 the first accounting node determines the target state data required by the current transaction in the state data, and backs up the target state data.
  • the nodes in the blockchain system may still be performing transactions. If these transactions are ignored, the accuracy of data archiving will be reduced. Therefore, in the embodiment of the present application, the first accounting node determines the target state data required by the current transaction among the state data included in the synchronized blockchain data, and backs up the target state data, where the current transaction is Transactions performed after the blockchain data is synchronized.
  • the first accounting node can directly archive the synchronized blockchain data, which can ensure data archiving Accuracy.
  • the above-mentioned first accounting node can determine the target state data required for the current transaction in the state data in this way: the first accounting node compares the synchronization block height with the archive block height Matching; when the synchronization block height matches the archive block height successfully, the first accounting node determines the target state data required for the current transaction in the state data.
  • conditions can be preset for data archiving.
  • the archive block height can be preset, and after obtaining the synchronization block height, the first accounting node matches the synchronization block height with the archive block height.
  • the first accounting node performs the operation of determining the target state data required for the current transaction in the state data; when the synchronization block height matches the archive block height failed, The first accounting node no longer performs subsequent operations.
  • the height of the archive block can be set according to actual application scenarios, and the number can be one or more.
  • the height of multiple archive blocks with the same interval can be set, such as an integer multiple of 10, specifically including 10, 20, ... 10 ⁇ n, where n is an integer greater than 1.
  • "synchronization block height and archive block height match successfully” can mean that the synchronization block height is the same as the archive block height, and "the synchronization block height is the same as the archive block height.
  • “Height matching failure” can mean that the synchronization block height is different from the archive block height; in the case where the number of archive block heights includes multiple, "the synchronization block height matches the archive block height successfully” can refer to the synchronization area The block height is the same as the height of a certain archive block. "The synchronization block height and the archive block height failed to match” can mean that the synchronization block height is different from the height of all archive blocks.
  • the first accounting node In step 103, the first accounting node generates a state data snapshot of the synchronization block height according to the target state data after the backup, and uses the state data snapshot, the synchronization block height and the signature information of the first accounting node as the archive point information. , And sent to the second accounting node.
  • the state data snapshot may be a snapshot obtained by performing a snapshot copy of the state data (here, the target state data after the backup).
  • the first accounting node may package the state data snapshot, the synchronization block height, and the signature information of the first accounting node into archive point information, and send the archive point information to the second accounting node. Among them, the first accounting node can sign the state data snapshot to obtain signature information.
  • step 104 the first billing node receives the endorsement information of the second billing node for the archive point information.
  • the endorsement information is used to indicate the approval of the archive point information by the second accounting node.
  • the second accounting node may verify the received archive point information, and sign the archive point information when the verification passes to obtain the endorsement information.
  • the second accounting node may verify the root hash value of the state data snapshot in the archive point information sent by the first accounting node.
  • the second accounting node will archive the point The information is approved, and the archive point information is signed to obtain the endorsement information for the archive point information.
  • the second accounting node can also broadcast the archive point information to other second accounting nodes.
  • it further includes: when the first accounting node receives the archive point information sent by the second accounting node, the first accounting node extracts the second accounting point from the archive point information.
  • the root hash value of the state data of the accounting node the first accounting node compares the root hash value of the state data of the second accounting node with the root hash value of the state data of the first accounting node; when the second accounting node When the root hash value of the state data of the accounting node is the same as the root hash value of the state data of the first accounting node, the first accounting node signs the archive point information to obtain the endorsement information of the archive point information; The accounting node sends the endorsement information to the second accounting node, and broadcasts the archive point information in the blockchain system.
  • the first accounting node may also receive the archiving point information sent by the second accounting node that requires data archiving.
  • the first accounting node extracts the root hash value of the state data of the second accounting node from the archive point information sent by the second accounting node, and compares the extracted root hash value with the first The root hash value of the state data of the accounting node is compared, and the method of generating the root hash value will be explained later.
  • the first accounting node signs the archive point information sent by the second accounting node, Obtain the endorsement information of the archive point information, and send the endorsement information to the second accounting node.
  • the archive point information sent by the second accounting node can also be broadcast in the blockchain system. Through the above method, the accuracy and effectiveness of the endorsement are improved.
  • the first accounting node archives the synchronized blockchain data according to the endorsement information and archiving point information.
  • the first accounting node can determine the target block data that needs to be deleted in the blockchain data after synchronization according to the endorsement information and archive point information, and delete the target block data, and at the same time, store the target block data
  • the distributed storage system here is different from the blockchain system.
  • the embodiment of the present application backs up the target state data required by the current transaction, and generates a state data snapshot based on the target state data after the backup, which solves the conflict between the snapshot and the original transaction, and realizes the status data
  • the embodiment of the present application backs up the target state data required by the current transaction, and generates a state data snapshot based on the target state data after the backup, which solves the conflict between the snapshot and the original transaction, and realizes the status data
  • let other accounting nodes in the blockchain system sign and endorse information such as state data snapshots, making this information credible, and therefore, can greatly improve the archiving efficiency and accuracy of blockchain data archiving .
  • Figure 2B is a schematic flow chart of the blockchain data archiving method provided by an embodiment of the present application.
  • Step 102 shown in Figure 2A can be implemented through steps 201 to 204, and each step will be combined. Be explained.
  • step 201 the first accounting node obtains the block height corresponding to the sub-state data and the storage tag in the local database.
  • the state data may include a plurality of sub-state data, and these sub-state data are stored in a local database (that is, the state database) of the first accounting node.
  • the storage tag may refer to a key-value pair K-V (key-value) in the local database, and each K (key) corresponds to a V (value).
  • K-V key-value
  • V value
  • the storage tag of a certain sub-state data in the local database can be K1-V1
  • K1 is the number of the sub-state data in the local database
  • V1 is the value corresponding to this number in the local database.
  • Different sub-state data may correspond to different block heights, and the first accounting node can determine the block height corresponding to the sub-state data according to the block number corresponding to the sub-state data. For example, if the first sub-state data corresponds to the first block (refers to the first block in the blockchain, the same applies to the following), it can be explained that the block height corresponding to the first sub-state data is 1; The third block corresponding to the two sub-state data can indicate that the block height corresponding to the second sub-state data is 3. The first accounting node can read the key-value pair corresponding to each sub-state data in the local database, and use the key-value pair as the storage tag of the sub-state data.
  • step 202 the first billing node adds the block height corresponding to the sub-state data to the storage tag corresponding to the sub-state data for marking, and the storage tag is obtained after the mark is obtained.
  • the first accounting node adds the block height corresponding to the sub-state data to the storage tag corresponding to the sub-state data to mark the storage tag.
  • the first accounting node may add a version number (Version) to the storage tag of the sub-state data, and the version number is the block height corresponding to the sub-state data. For example, if the block height corresponding to a certain sub-state data is 5 and the storage label is (K1-V1), after adding the version number (block height) to the storage label, the storage label after marking can be (K1 -V1, version (5)).
  • the first accounting node selects the target sub-state data required by the current transaction from the multiple sub-state data according to the stored tag after the mark.
  • the above-mentioned first billing node can be implemented in this way to filter out the target sub-state data required by the current transaction from the multiple sub-state data according to the stored tag after the mark: the first billing node obtains Transaction information corresponding to the current transaction; the first accounting node determines the current block height of the current blockchain data of the first accounting node according to the transaction information; when the current block height exceeds the synchronization block height, the first accounting node The node determines that there is a new block in the current blockchain data; the first accounting node filters out the call information required by the transaction in the new block from the current blockchain data, and the call information is used to indicate the sub-state data of the call; first The accounting node stores the label according to the calling information and the label, and filters out the target sub-state data from multiple sub-state data.
  • the first accounting node will receive the consensus node For the new block sent, at this time, the first accounting node can determine the current block height according to the current block chain data.
  • the current blockchain data is not necessarily the synchronized blockchain data.
  • the current blockchain data continues to generate transactions after the blockchain data is synchronized, thereby updating the synchronized blockchain data The obtained blockchain data. Therefore, the block height of the current blockchain data and the synchronized blockchain data may be different. If there is no transaction information in the current transaction (equivalent to the absence of the current transaction), it means that the current blockchain data at this time is equal to the synchronized blockchain data.
  • the first accounting node determines that there is a new block in the current block chain data, and filters out the calling information needed for the transaction in the new block from the current block chain data, and calls
  • the information is used to indicate the sub-status data of the call.
  • the calling information can be used to indicate which sub-state data of which block height in the state data needs to be called for the current transaction. For example, the sub-state data with a block height of 3 and a sub-state data value of V1 needs to be called.
  • the first billing node determines the label of the sub-state data that needs to be called and stores the label according to the calling information, and filters out the target sub-state data in the state data according to the determined labeling storage label, for example, or uses the calling information to indicate the need to call
  • the first accounting node can determine the label of the target sub-state data that needs to be called and store the label as (K1-V1, version (3))
  • the first billing node stores the label according to this mark, and can filter out the target sub-state data in the state data.
  • the target status data includes all target sub-status data filtered out here.
  • the first accounting node can stop performing subsequent operations, that is, stop data archiving.
  • step 204 the first accounting node backs up the target sub-state data.
  • the first accounting node can back up the target sub-state data after filtering and obtaining the target sub-state data.
  • the above-mentioned first accounting node can back up the target sub-state data in such a way: the first accounting node filters out the transaction operation information required by the transaction in the new block from the transaction information; An accounting node determines the transaction operation type corresponding to the target sub-state data according to the transaction operation information; when the transaction operation type is an update operation, the first accounting node backs up the target sub-state data corresponding to the update operation; when the transaction operation type For the deletion operation, the first accounting node backs up the target sub-state data corresponding to the deletion operation, and adds a delete label to the target sub-state data after the backup; the delete label is used to indicate that the target sub-state data after the backup is in It cannot be read during transaction execution.
  • the first accounting node can filter out the transaction operation information required by the transaction in the new block from the transaction information of the current blockchain data.
  • the transaction operation information contains the operation type of the target sub-state data called during the transaction.
  • the usual operation types can include update and delete.
  • the first accounting node determines the transaction operation type corresponding to the target sub-state data according to the transaction operation information. For example, the transaction operation type of each target sub-state data in the transaction operation information is one-to-one correspondence, and finally, each target sub-state data is obtained. The type of transaction operation corresponding to the status data.
  • the first accounting node backs up the target sub-state data according to the transaction operation type of the target sub-state data.
  • the transaction operation type of the target sub-state data is an update operation
  • the target sub-state data corresponding to the update operation will be updated.
  • Perform backup directly For example, if the storage tag of the target sub-state data corresponding to the update operation is (K1-V1, version (5)), then this sub-state data can be backed up directly.
  • the block height of the new block in FIG. 3 refers to the current block height.
  • the first accounting node When the transaction operation type of the target sub-state data is a delete operation, the first accounting node backs up the target sub-state data corresponding to the delete operation, and adds a delete label to the target sub-state data after the backup, for example, as shown in Figure 3
  • the storage label is (K3-V3, version (4)) as an example.
  • the first accounting node directly backs up the target sub-state data and is the target after the backup.
  • the deletion tag can be any identifier, for example, it can be deleted, D, it can be the Chinese character "deleted", or it can be other deletion identifiers.
  • Adding a deletion label to the target sub-state data after the backup may refer to adding the deletion label to the marked storage label corresponding to the target sub-state data after the backup, so as to update the marked storage label.
  • the post-marked storage label corresponding to the target sub-state data after the backup can be updated to (K3-V3, version (4), delete).
  • the first accounting node adds a deletion tag to the backed up target sub-state data
  • the backed-up target sub-state data cannot be read during subsequent transactions.
  • step 103 shown in FIG. 2A can be implemented through step 205 to step 209, which will be described in combination with each step.
  • step 205 the first accounting node filters out the synchronization sub-state data whose block height does not exceed the height of the synchronization block from the state data, and obtains the synchronization sub-state data set.
  • the first accounting node stores tags according to the sub-state data in the state data, and filters out the sub-state data whose block height does not exceed the height of the synchronization block.
  • the sub-state data filtered out here is named To synchronize the sub-state data. Taking the synchronization block height as an example of 5, the first accounting node can filter out the sub-state data whose block height does not exceed 5 in the local database after the tag is stored, and use these filtered sub-state data as synchronization The sub-state data is added to the synchronized sub-state data collection.
  • step 206 the first accounting node uses the backed up target sub-state data as the new synchronization sub-state data and adds it to the synchronization sub-state data set to update the synchronization sub-state data set.
  • the target sub-state data corresponding to the update operation in the state data of the first accounting node may have been updated, that is, the synchronized sub-state data set obtained in step 205 includes Is the target sub-state data that has been updated; the target sub-state data corresponding to the deletion operation in the state data of the first accounting node may have been deleted, that is, the synchronization sub-state data set obtained in step 205 does not include deletion The target sub-state data corresponding to the operation.
  • the first accounting node uses the backed up target sub-state data as the new synchronization sub-state data and adds it to the synchronization sub-state data.
  • the state data set in order to realize the update of the synchronized sub-state data set.
  • the target state data after the backup may include the target sub-state data corresponding to the update operation of the backup, and the target sub-state data after the backup with the added or deleted tag, the two cases will be described separately.
  • the first accounting node uses the target sub-state data corresponding to the backup update operation to replace the corresponding synchronization sub-state data in the synchronization sub-state data set. For example, take the target sub-state data corresponding to the update operation as (K1-V1, version (5)), which is updated to (K1-V1', version (5+1)) in the transaction of the new block, in step 205
  • the obtained synchronization sub-state data set also includes (K1-V1', version (5+1)).
  • the first accounting node uses the previously backed up (K1-V1, version (5)) to replace (K1-V1', version (5+1)) in the synchronized sub-state data set, so that it can Ensure the accuracy of subsequent state data snapshots.
  • step 205 For the target sub-state data corresponding to the delete operation, take (K3-V3, version (4)) as an example. Since (K3-V3, version (4)) has been deleted during the current transaction, step 205 is obtained The post-synchronization sub-state data set does not include (K3-V3, version (4)). Therefore, the target sub-state data after the backup with the added and deleted tags, namely (K3-V3, version (4)), is added to the synchronized sub-state data set to supplement the deleted (K3-V3, version (4) ))s position.
  • the corresponding sub-state data is represented by storing tags after marking.
  • the above method can obtain the updated synchronized sub-state data set through the operation of replacement and addition.
  • the first accounting node can ensure that the state data within the height of the synchronized block Integrity, and further, can ensure the accuracy of the state data snapshot of the synchronized block obtained when the state data is snapshotted.
  • step 207 the first accounting node performs a hash operation on the synchronized sub-state data in the updated synchronized sub-state data set to generate state data of the target structure.
  • the target structure may be a Merkle Tree, which of course does not constitute a limitation to the embodiments of the present application.
  • the above-mentioned first accounting node can perform a hash operation on the synchronized sub-state data in the updated synchronized sub-state data set to generate the state data of the target structure in this way:
  • the accounting node classifies the multiple synchronization sub-state data in the updated synchronization sub-state data set to obtain multiple types of synchronization sub-state data; the first accounting node performs data processing on multiple types of synchronization sub-state data respectively.
  • the leaf hash values corresponding to multiple types of synchronized sub-state data are obtained; the first accounting node performs hash operations according to the leaf hash values corresponding to multiple types of synchronized sub-state data to obtain the root hash Value; the first accounting node generates the state data of the target structure according to the root hash value and the leaf hash values corresponding to multiple types of synchronized sub-state data, respectively.
  • the embodiment of the present application provides a schematic diagram of the state data of the target structure as shown in FIG. V10) is explained as an example.
  • the first accounting node can classify all the synchronization sub-state data in the synchronization sub-state data set. For example, it can classify according to the setting order of the keys in the storage tag (or the storage tag after marking), and limit each The number of synchronized sub-state data included in a type does not exceed the type number threshold, where the key setting order can be from small to large or from large to small, and the type number threshold can be set according to actual application scenarios. If set to 3.
  • (K1-V1), (K2-V2) and (K3-V3) can be divided into the first category, and (K4-V4), (K5-V5) and (K6-V6) Divided into the second category, (K7-V7), (K8-V8) and (K9-V9) are divided into the third category, and (K10-V10) alone as the fourth category.
  • the intermediate hash values h5 and h6 are hashed to obtain the root hash value h7.
  • the state data of the target structure is generated.
  • a Merkel tree can be constructed based on these hash values, and the hash values h1, h2, h3, and h4 corresponding to the four types can be used as
  • h5 and h6 are used as the intermediate hash value of the Merkel tree
  • h7 is used as the root hash value (Root Hash) of the Merkel tree.
  • step 208 the first accounting node copies the state data of the target structure to generate a state data snapshot of the synchronization block height.
  • the first accounting node copies the generated state data of the target structure to obtain a state data snapshot of the synchronization block height.
  • the state of the generated Merkel tree can be copied to obtain a snapshot of the Merkel tree, as shown in Figure 4.
  • the first accounting node uses the state data snapshot, the synchronization block height, and the signature information of the first accounting node as archive point information, and sends it to the second accounting node.
  • the first accounting node signs the state data snapshot to obtain signature information. Then, the first accounting node packs the signature information, the state data snapshot and the synchronization block height into archive point information, and sends the archive point information to the second accounting node of the blockchain system.
  • the embodiment of the present application filters the target sub-state data according to the stored tags after marking, which can improve the efficiency and accuracy of the screening; according to the backup target sub-state data, the synchronized sub-state data set is updated to ensure the update The data integrity and data accuracy of the subsequent synchronized sub-state data collection.
  • Figure 2C is a schematic flow chart of a blockchain data archiving method provided by an embodiment of the present application. Step 105 shown in Figure 2A can be implemented through steps 301 to 304, and each step will be combined. Be explained.
  • the first billing node determines the number of endorsements of the second billing node that sends endorsement information.
  • the first billing node determines the number of second billing nodes that send endorsement information according to the received endorsement information, as the endorsement number. For example, if the first billing node receives 5 pieces of endorsement information, it can be determined that the number of second billing nodes that send endorsement information is 5, that is, the number of endorsements is 5.
  • step 302 when the number of endorsements exceeds the number threshold, the first accounting node adds the endorsement information to the archive point information to obtain updated archive point information.
  • the number threshold can be set according to actual application scenarios, for example, it can be 1/2, 1/3, or other proportions of the total number of second accounting nodes included in the blockchain system, or it can be set directly It is 3, 5, or 7 values.
  • the first accounting node adds the endorsement information to the archive point information to update the archive point information to obtain updated archive point information.
  • the endorsement information in the updated archive point information and the signature information of the first accounting node can jointly constitute the signature evidence information for the state data of the synchronization block height.
  • step 303 the first accounting node sends the updated archive point information to the consensus node.
  • the first accounting node sends the updated archive point information to the consensus node, and the consensus node determines whether to generate configuration block data according to the updated archive point information.
  • the configuration block data is obtained by generating the configuration block by the consensus node and storing the updated archive point information in the configuration block.
  • step 303 it further includes: the consensus node screens out the endorsement information and signature information from the updated archive point information; the consensus node verifies the endorsement information and signature information; when the consensus node verifies the endorsement information and signature information When the information verification is passed, the consensus node generates a configuration block, and stores the updated archive point information in the configuration block to obtain the configuration block data; the consensus node sends the configuration block data to the first accounting node and the second accounting node Account node.
  • the first accounting node sends the updated archive point information to the consensus node, and the consensus node filters out the endorsement information and signature information from the updated archive point information, and verifies the endorsement information and signature information, that is, the endorsement information
  • the signature evidence information composed of the signature information of the first accounting node is verified.
  • the consensus node can verify the amount of endorsement information. For example, when the amount of endorsement information exceeds the quantity threshold (which can be the same as the quantity threshold in step 302), it is determined that the endorsement information has passed the verification; When the quantity does not exceed the quantity threshold, it is determined that the verification of the endorsement information has failed.
  • the consensus node can also verify the identity of the second billing node corresponding to the endorsement information. For example, when there is a second billing node corresponding to each endorsement information in the blockchain system, it is determined that the endorsement information has passed the verification. ; When there is no second accounting node corresponding to one or more background information in the blockchain system, it is determined that the endorsement information verification fails.
  • the consensus node may verify the signature information of the first accounting node according to at least one of the set signature format and signature rules.
  • the signature format As an example, when the signature information of the first accounting node conforms to the signature format, it is determined that the signature information is verified; when the signature information of the first accounting node does not conform to the signature format, it is determined to verify the signature information. The test failed.
  • the verification process according to the signature rules is the same. It is worth noting that, in the case of verifying the signature information of the first accounting node according to the signature format and signature rules, only when the signature information of the first accounting node meets both the signature format and the signature rules, the verification The signature information is verified.
  • the verification rules for the endorsement information and signature information of the consensus node are not limited to the above examples, and can be set according to actual application scenarios.
  • the endorsement information can be verified according to specific endorsement rules or endorsement requirements.
  • the consensus node passes the verification of the endorsement information and the signature information, the consensus node generates a configuration block, and stores the updated archive point information in the configuration block to obtain the configuration block data. Then, the consensus node sends the configuration block data to the first accounting node and the second accounting node.
  • step 304 when the first accounting node receives the configuration block data sent by the consensus node for the updated archive point information, the first accounting node archives the synchronized blockchain data.
  • the first accounting node when the first accounting node receives the configuration block data sent by the consensus node for the updated archive point information, it proves that the consensus node has approved the updated archive point information, so the first accounting node pairs the synchronized blockchain data File it.
  • the above-mentioned first accounting node can archive the synchronized blockchain data in this way: the first accounting node copies the updated archive point information to generate the first accounting A snapshot of the archived data of the node at the height of the synchronization block; the first accounting node adds the configuration block data to the first block data to obtain the updated first block data; the first accounting node is in the first area after the update From the block data, the target block data whose block height does not exceed the synchronization block height is filtered out; the first accounting node deletes the target block data.
  • the first accounting node copies the synchronization block height, signature information, and endorsement information in the updated archive information to obtain data snapshots corresponding to these data, and then copies the data snapshots corresponding to these data and the updated archive information.
  • the state data snapshots together constitute a synchronized block-high archive data snapshot, and the archive data snapshot is stored locally.
  • the first accounting node adds the configuration block data to the first block data to update the first block data to obtain the updated first block data, where the first block data refers to the synchronization Blocks included in post-blockchain data.
  • the first accounting node filters out the block data whose block height does not exceed the synchronization block height from the updated first block data.
  • the block data selected here is named the target block data.
  • the embodiment of the present application provides a schematic diagram of data archiving as shown in FIG. From the ordinary block data, ordinary blocks whose block height does not exceed H are further screened out as target block data. As shown in FIG. 5, the target block data includes ordinary block 0 to ordinary block H.
  • the ordinary block data refers to the block data that is different from the configuration block data in the updated first block data.
  • H in FIG. 5 is an integer greater than or equal to 0, and N is an integer greater than H.
  • the method further includes: when the second accounting node receives the configuration block data sent by the consensus node, the second accounting node checks the signature information, endorsement information, and status in the configuration block data.
  • the data snapshot and the synchronization block height are copied to obtain the archived data snapshot of the synchronization block height; the second accounting node adds the configuration block data to the blockchain data of the second accounting node, and the updated first From the blockchain data of the second accounting node, the target block data whose block height does not exceed the height of the synchronization block is filtered out; the second accounting node deletes the target block data.
  • the consensus node After generating the configuration block data, the consensus node sends the configuration block data to the first accounting node and the second accounting node.
  • the second accounting node receives the configuration block data
  • the second accounting node extracts the signature information, endorsement information, state data snapshot and synchronization block height in the configuration block data, and copies the extracted data Obtain a snapshot of archived data at the height of the synchronization block, and store the archived data snapshot locally.
  • the second accounting node may also add the configuration block data to the local blockchain data of the second accounting node to obtain the updated blockchain data of the second accounting node. Then, the second billing node filters out the target block data whose block height does not exceed the height of the synchronization block from the updated block chain data of the second billing node (for easy distinction, named as the second billing node Target block data), and delete the target block data of the second accounting node to complete data archiving.
  • the data archiving of the second accounting node can also be realized, thereby saving storage resources of all accounting nodes in the blockchain system.
  • the process of archiving target block data that does not exceed the synchronization block height by the first accounting node and the second accounting node may be performed at the same time or at different times.
  • the entire archiving process can be shown in Figure 6.
  • the archiving consensus in Figure 6 refers to the operations performed by the consensus node during the data archiving process.
  • the target block data can also be stored in a distributed storage system.
  • the distributed storage system is different from the blockchain system, and the distributed storage system can be used for cold storage ( Cold Storage, that is, the stored data is not often accessed; the blockchain system can be used for hot storage, that is, the stored data is often accessed.
  • it further includes: when the first accounting node is a newly added accounting node in the blockchain system, the first accounting node sends a synchronization request to the consensus node and receives the consensus The endorsement information and archiving point information sent by the node in response to the synchronization request; the first accounting node obtains state data from the second accounting node according to the endorsement information and archiving point information; the first accounting node obtains the status data from the consensus node or the second accounting node Obtain the second block data whose block height exceeds the synchronization block height; the first accounting node updates the state data according to the transaction information in the second block data to obtain the current blockchain data of the first accounting node .
  • the first accounting node When the first accounting node is a newly added accounting node in the blockchain system, the first accounting node needs to obtain the locally stored blockchain data from the blockchain system, that is, in the embodiment of this application, except In addition to the demand for data archiving, there is also a demand for data acquisition.
  • the first accounting node can send a synchronization request to the consensus node, and when the consensus node receives the synchronization request, it sends endorsement information and archive point information for the synchronization request to the first accounting node.
  • the first accounting node obtains status data from the second accounting node according to the received endorsement information and filing point information.
  • the first accounting node can also obtain block data whose block height exceeds the synchronization block height from the consensus node or the second accounting node.
  • the block data obtained here is named the second block data.
  • the synchronization block height here may refer to the synchronization block height obtained after the second accounting node performs the blockchain data synchronization.
  • the first accounting node when the synchronization block height is 5, the first accounting node obtains block data with a block height exceeding 5 from the consensus node or the second accounting node as the second block data. Then, the first billing node updates the state data according to the transaction information in the second block data. For example, the world state of the first billing node can be reviewed by replaying the transactions in the block included in the second block data. Update to synchronize to the latest world state in the consensus node and the second accounting node, and obtain the current blockchain data of the first accounting node.
  • the newly added accounting node in the blockchain system can obtain accurate and effective current blockchain data, and the accuracy of data acquisition can be improved.
  • the above-mentioned first billing node can obtain status data from the second billing node according to the endorsement information and archiving point information in this way: the first billing node compares the endorsement information and the second billing The signature information of the accounting node is verified; when the first accounting node verifies the endorsement information and the signature information of the second accounting node, the first accounting node determines the multiple leaf hash values corresponding to the root hash value ; The first accounting node obtains the sub-state data corresponding to different leaf hash values in parallel from the second accounting node as the obtained state data.
  • the first accounting node when it receives the endorsement information and archiving point information, it can check the signature information of the second accounting node (here, the accounting node for data archiving) in the endorsement information and archiving point information.
  • the verification rules There are no restrictions on the verification rules here, and the verification rules of the consensus nodes mentioned above can be used.
  • the first accounting node determines the corresponding multiple leaf hash values according to the root hash value in the archive point information.
  • the archive point information received by the first accounting node includes the root hash value of the state data of the consensus node and the signature information of the second accounting node.
  • the root hash value is h7
  • the first accounting node can determine the root hash according to the Merkel tree
  • the leaf hash values corresponding to the values include h1, h2, h3, and h4.
  • the first accounting node can obtain the sub-state data corresponding to different leaf hash values in parallel from the second accounting node, and use all the obtained sub-state data together as the obtained state data.
  • the first accounting node may obtain sub-state data corresponding to all leaf hash values from a single second accounting node, or may obtain different sub-state data from different second accounting nodes.
  • the above-mentioned first accounting node can obtain the sub-state data corresponding to different leaf hash values from the second accounting node in parallel in this way: the first accounting node performs accounting according to the second accounting The number of nodes classifies multiple leaf hash values; the first accounting node determines the target leaf hash values corresponding to different second accounting nodes according to the classification results of multiple leaf hash values; first accounting The node obtains the sub-state data corresponding to the hash value of the target leaf from a different second accounting node.
  • the first accounting node can divide h1 and h2 into one category, and h3 and h4 into one category. Then, the first accounting node determines the target leaf hash value corresponding to the second accounting node according to the classification result. For example, the first accounting node can classify h1 and h2 as the second accounting node. For the target leaf hash value corresponding to A, the other types of h3 and h4 are both used as the target leaf hash value corresponding to the second accounting node B.
  • the first accounting node obtains the sub-state data corresponding to the target leaf hash value from the second accounting node according to the target leaf hash value corresponding to the second accounting node.
  • the first accounting node can obtain the sub-state data (K1-V1) to (K3-V3) corresponding to h1 and the sub-state data (K4-V4) corresponding to h2 from the second accounting node A.
  • K6-V6 obtains sub-state data (K7-V7) to (K9-V9) corresponding to h3 and the sub-state data (K10-V10) corresponding to h4 from the second accounting node B.
  • the first accounting node can construct the local world state of the first accounting node.
  • obtaining different sub-state data from different second accounting nodes can reduce the processing pressure of each second accounting node, and at the same time can improve the accuracy of the obtained state data.
  • the embodiment of the application sends the updated archive information to the consensus node, and when the configuration block data sent by the consensus node for the updated archive information is received, the synchronized blockchain data is archived, Can effectively improve the effectiveness and accuracy of archiving.
  • FIG. 9 is a schematic flowchart of a blockchain data archiving method provided by an embodiment of the present application, which will be described in conjunction with the steps shown in FIG. 9.
  • step 401 the first accounting node synchronizes blockchain data with the consensus node, and determines the synchronization block height of the synchronized blockchain data.
  • step 402 when the synchronization block height matches the archive block height successfully, the first accounting node obtains the block height corresponding to the sub-state data and the storage tag in the local database.
  • step 403 the first billing node adds the block height corresponding to the sub-state data to the storage tag corresponding to the sub-state data for marking, and the storage tag is obtained after the mark is obtained.
  • step 404 the first accounting node selects the target sub-state data required for the current transaction from the multiple sub-state data according to the stored tag after the mark.
  • step 405 the first accounting node backs up the target sub-state data.
  • the first accounting node In step 406, the first accounting node generates a state data snapshot of the synchronization block height according to the target sub-state data after the backup, and uses the state data snapshot, the synchronization block height and the signature information of the first accounting node as the archive point. Information and sent to the second accounting node.
  • step 407 the second accounting node generates endorsement information for the archive point information, and sends the endorsement information to the first accounting node.
  • the first billing node receives the endorsement information of the second billing node for the archive point information.
  • the first billing node determines the number of endorsements of the second billing node that sent the endorsement information.
  • step 410 when the number of endorsements exceeds the number threshold, the first accounting node adds the endorsement information to the archive point information, obtains the updated archive point information, and sends the updated archive point information to the consensus node.
  • step 411 the consensus node generates configuration block data according to the updated archive point information, and sends the configuration block data to the first accounting node and the second accounting node.
  • step 412 when the first accounting node receives the configuration block data sent by the consensus node, the first accounting node archives the synchronized blockchain data.
  • step 413 when the second accounting node receives the configuration block data, the second accounting node archives the blockchain data of the second accounting node.
  • the first accounting node when the first accounting node is a newly added accounting node in the blockchain system, the first accounting node can obtain the latest blockchain data from the blockchain system, which will be combined with Figure 10 The steps shown are explained.
  • step 414 the first accounting node sends a synchronization request to the consensus node.
  • step 415 the consensus node sends the endorsement information and archive point information to the first accounting node according to the synchronization request.
  • the first accounting node obtains status data from the second accounting node according to the endorsement information and the filing point information.
  • step 417 the first accounting node obtains the second block data whose block height exceeds the synchronization block height from the consensus node or the second accounting node.
  • the first billing node updates the state data according to the transaction information in the second block data to obtain the current blockchain data of the first billing node.
  • the embodiment of the present application can back up the target state data required by the current transaction, and generate a state data snapshot based on the target state data after the backup, which solves the conflict between the snapshot and the original transaction, and realizes Real-time snapshots of state data; and let other accounting nodes in the blockchain system sign and endorse information such as state data snapshots, making this information credible, and therefore, can greatly improve the archiving efficiency and efficiency of blockchain data archiving Filing accuracy; in addition, in addition to data archiving, the embodiments of this application aim at newly-added accounting nodes. By sending endorsement information, archive point information, and second block data, the newly-added accounting nodes can obtain Accurate current blockchain data can get a concise and accurate ledger.
  • an embodiment of the present application also provides a blockchain data archiving device.
  • the blockchain data archiving device can be integrated in an electronic device, such as a server or a terminal.
  • the terminal can include a tablet computer. , Laptops and/or personal computers, etc.
  • the device for generating blockchain data archives may include a synchronization unit 301, a determining unit 302, a generating unit 303, a receiving unit 304, and an archiving unit 305.
  • the synchronization unit 301 is configured to synchronize the blockchain data between the first accounting node and the consensus node and determine the synchronization block height of the synchronized blockchain data.
  • the synchronized blockchain data includes state data; the determining unit 302 is configured Determine the target state data required by the current transaction for the first accounting node in the state data, and back up the target state data; the generating unit 303 is configured to generate the synchronization block according to the backup target state data by the first accounting node High-level state data snapshot, the state data snapshot, synchronization block height, and signature information of the first accounting node are used as archive point information, and sent to the second accounting node; the receiving unit 304 is configured as the first accounting node Receive the endorsement information of the second accounting node for the archive point information; the archiving unit 305 is configured to archive the synchronized blockchain data according to the endorsement information and archive point information by the first accounting node.
  • the state data includes multiple sub-state data
  • the determining unit 302 may include an obtaining sub-unit 3021, an adding sub-unit 3022, a filtering sub-unit 3023, and a backup sub-unit 3024, as shown in FIG. 12.
  • Obtaining sub-unit 3021 configured as the first accounting node to obtain the block height corresponding to the sub-state data and the storage tag in the local database; adding sub-unit 3022, configured as the block corresponding to the sub-state data by the first accounting node The height is added to the storage tag corresponding to the sub-state data for marking, and the tag is stored after the tag is obtained; the filtering subunit 3023 is configured as the first accounting node to filter the current exchange from the multiple sub-state data according to the marked storage tag The required target sub-state data; the backup sub-unit 3024 is configured as the first accounting node to back up the target sub-state data.
  • the screening subunit 3023 is configured to: the first accounting node obtains transaction information corresponding to the current transaction; the first accounting node determines the current blockchain data of the first accounting node according to the transaction information Block height; when the current block height exceeds the synchronization block height, the first accounting node determines that there is a new block in the current blockchain data; the first accounting node filters out the new block in the current blockchain data
  • the call information required by the transaction the call information is used to indicate the sub-state data to be called; the first accounting node stores the tag according to the call information and the tag, and filters out the target sub-state data from the multiple sub-state data.
  • the backup subunit 3024 is configured to: the first accounting node screens out the transaction operation information required by the transaction in the new block from the transaction information; the first accounting node determines the target sub-state according to the transaction operation information The transaction operation type corresponding to the data; when the transaction operation type is an update operation, the first accounting node will back up the target sub-state data corresponding to the update operation; when the transaction operation type is a delete operation, the first accounting node will delete the operation The corresponding target sub-state data is backed up, and a delete tag is added to the backed-up target sub-state data; where the delete tag is used to indicate that the backed-up target sub-state data cannot be read during transaction execution.
  • the generating unit 303 is configured to: the first billing node filters out the synchronization sub-state data whose block height does not exceed the height of the synchronization block from the state data to obtain the synchronization sub-state data set; The node takes the backed-up target sub-state data as the new synchronization sub-state data and adds it to the synchronization sub-state data set to update the synchronization sub-state data set; the first accounting node compares the data in the updated synchronization sub-state data set The synchronization sub-state data is hashed to generate the state data of the target structure; the first accounting node copies the state data of the target structure to generate a state data snapshot of the synchronization block height.
  • the generating unit 303 is configured to: the first accounting node classifies multiple synchronization sub-state data in the updated synchronization sub-state data set to obtain multiple types of synchronization sub-state data; The accounting node performs hash operations on multiple types of synchronized sub-state data to obtain leaf hash values corresponding to multiple types of synchronized sub-state data; the first accounting node respectively performs a hash operation on multiple types of synchronized sub-state data.
  • the corresponding leaf hash value is hashed to obtain the root hash value; the first accounting node generates the state data of the target structure according to the root hash value and the leaf hash values corresponding to multiple types of synchronized sub-state data. .
  • the archiving unit 305 may include a determining subunit 3051, an updating subunit 3052, a sending subunit 3053, and an archiving subunit 3054, as shown in FIG. 13.
  • the determining subunit 3051 is configured as the first accounting node to determine the number of endorsements of the second accounting node that sends the endorsement information
  • the update subunit 3052 is configured to add the endorsement information to the first accounting node when the number of endorsements exceeds the number threshold In the archive point information, the updated archive point information is obtained
  • the sending subunit 3053 is configured as the first accounting node to send the updated archive point information to the consensus node
  • the archive subunit 3054 is configured to be received when the first accounting node receives When the consensus node sends the configuration block data for the updated archive point information, the first accounting node archives the synchronized blockchain data.
  • the synchronized blockchain data includes the first block data; the archive subunit 3054 is configured to: the first accounting node copies the updated archive point information to generate the first accounting node in the synchronization A snapshot of the archived data of the block height; the first accounting node adds the configuration block data to the first block data to obtain the updated first block data; the first accounting node is in the updated first block data The target block data whose block height does not exceed the synchronization block height is filtered out; the first accounting node deletes the target block data.
  • the archiving subunit 3054 is configured to: when the first accounting node deletes the target block data, the first accounting node stores the target block data in the distributed storage system; wherein, the distribution The storage system is different from the blockchain system.
  • the sending subunit 3053 is configured to: the consensus node screens out the endorsement information and signature information from the updated archive point information; the consensus node verifies the endorsement information and the signature information; when the consensus node checks the endorsement information and When the signature information is verified, the consensus node generates a configuration block, and stores the updated archive point information in the configuration block to obtain the configuration block data; the consensus node sends the configuration block data to the first accounting node and the second accounting node. Accounting node.
  • the sending subunit 3053 is configured to: the consensus node verifies at least one of the number of endorsement information and the identity of the second accounting node corresponding to the endorsement information; the consensus node verifies according to the signature format and At least one of the signature rules verifies the signature information.
  • the blockchain data archiving device may further include an endorsement unit 306, as shown in FIG. 14.
  • the endorsement unit 306 is configured to, when the first accounting node receives the archive point information sent by the second accounting node, the first accounting node extracts the root hash of the state data of the second accounting node from the archive point information Value; the first accounting node compares the root hash value of the state data of the second accounting node with the root hash value of the state data of the first accounting node; when the root hash value of the state data of the second accounting node When the value is the same as the root hash value of the state data of the first accounting node, the first accounting node signs the archive point information to obtain the endorsement information of the archive point information; the first accounting node sends the endorsement information to the first accounting node. Second, the accounting node, and broadcast the archive point information in the blockchain system.
  • the blockchain data archiving device may further include an update unit 307, as shown in FIG. 15.
  • the update unit 307 is configured to send a synchronization request to the consensus node by the first accounting node, and receive endorsement information and archiving point information sent by the consensus node in response to the synchronization request; the first accounting node obtains data from the second accounting node according to the endorsement information and archiving point information.
  • the accounting node obtains the state data; the first accounting node obtains the second block data whose block height exceeds the synchronization block height from the consensus node or the second accounting node; the first accounting node according to the second block data Transaction information, the status data is updated, and the current blockchain data of the first accounting node is obtained.
  • the archive point information includes the root hash value of the state data of the consensus node and the signature information of the second accounting node;
  • the update unit 307 is configured to: the first accounting node endorses the information and the second accounting The signature information of the node is verified; when the first billing node passes the verification of the endorsement information and the signature information of the second billing node, the first billing node determines multiple leaf hash values corresponding to the root hash value; The first accounting node obtains the sub-state data corresponding to different leaf hash values in parallel from the second accounting node as the obtained state data.
  • the update unit 307 is configured to: the first accounting node classifies the multiple leaf hash values according to the number of the second accounting nodes; the first accounting node classifies the multiple leaf hash values according to the According to the classification result of, determine the target leaf hash value corresponding to different second accounting nodes; the first accounting node obtains the sub-state data corresponding to the target leaf hash value from the different second accounting nodes.
  • the synchronization unit 301 is configured to: the first accounting node sends a synchronization request to the consensus node, the synchronization request includes the identity of the first accounting node; the first accounting node receives the synchronization request sent by the consensus node Block; among them, the block is sent when the consensus node verifies the identity of the first accounting node in the synchronization request; the first accounting node responds to the local blockchain data according to the block sent by the consensus node Update to get the synchronized blockchain data.
  • the determining unit 302 is configured to: the first accounting node matches the synchronization block height with the archive block height; when the synchronization block height matches the archive block height successfully, the first accounting node Determine the target state data required by the current transaction in the state data.
  • each of the above units can be implemented as an independent entity, or can be combined arbitrarily, and implemented as the same or several entities.
  • each of the above units please refer to the previous method embodiments.
  • the embodiment of the present application also provides an electronic device, as shown in FIG. 16, which shows a schematic structural diagram of the electronic device involved in the embodiment of the present application.
  • the electronic device may include one or more processing core processors 401, One or more components such as the memory 402, the power supply 403, and the input unit 404 of one or more computer-readable storage media.
  • processing core processors 401 One or more components such as the memory 402, the power supply 403, and the input unit 404 of one or more computer-readable storage media.
  • FIG. 16 does not constitute a limitation on the electronic device, and may include more or fewer components than shown in the figure, or a combination of certain components, or different component arrangements.
  • the processor 401 is the control center of the electronic device. It uses various interfaces and lines to connect the various parts of the entire electronic device, runs or executes the software programs and/or modules stored in the memory 402, and calls Data, perform various functions of electronic equipment and process data, so as to monitor the electronic equipment as a whole.
  • the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, where the application processor mainly processes the operating system, user interface, application programs, etc. , The modem processor mainly deals with wireless communication. It can be understood that the foregoing modem processor may not be integrated into the processor 401.
  • the memory 402 may be used to store software programs and modules.
  • the processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402.
  • the memory 402 may mainly include a program storage area and a data storage area.
  • the program storage area may store an operating system, an application program required by at least one function (such as a sound playback function, an image playback function, etc.), etc.; Data created by the use of electronic equipment, etc.
  • the memory 402 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state storage devices.
  • the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.
  • the electronic device also includes a power supply 403 for supplying power to various components.
  • the power supply 403 may be logically connected to the processor 401 through a power management system, so that functions such as charging, discharging, and power consumption management can be managed through the power management system.
  • the power supply 403 may also include any components such as one or more DC or AC power supplies, a recharging system, a power failure detection circuit, a power converter or inverter, and a power status indicator.
  • the electronic device may further include an input unit 404, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.
  • an input unit 404 which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.
  • the electronic device may also include a display unit and the like.
  • the processor 401 in the electronic device will load the executable file corresponding to the process of one or more application programs into the memory 402 according to the following instructions, and the processor 401 will run and store the executable file in the memory.
  • the application program (executable instruction) in 402 realizes various functions, as follows:
  • the first accounting node synchronizes the blockchain data with the consensus node, and determines the synchronization block height of the synchronized blockchain data.
  • the blockchain data includes state data; the first accounting node determines the current state in the state data
  • the target state data required by the transaction and the target state data are backed up; the first accounting node generates a state data snapshot of the synchronization block height according to the target state data after the backup, and the state data snapshot, the synchronization block height and the first
  • the signature information of the accounting node is collectively used as the archiving point information and sent to the second accounting node; the first accounting node receives the endorsement information of the second accounting node for the archiving point information; the first accounting node uses the endorsement information and filing Click the information to archive the blockchain data after synchronization.
  • the implementation of the above operations can refer to the previous embodiments.
  • the embodiment of the present application can back up the target state data required by the current transaction, and generate a state data snapshot based on the backed up target state data, solve the conflict problem between the snapshot and the original transaction, and realize the real-time status data Snapshots, and allow other accounting nodes in the blockchain to sign and endorse information such as state data snapshots, making this information credible, and therefore, can greatly improve the archiving efficiency and accuracy of blockchain data archiving.
  • an embodiment of the present application provides a computer program product or computer program.
  • the computer program product or computer program includes executable instructions, and the executable instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the executable instruction from the computer-readable storage medium, and the processor executes the executable instruction, so that the computer device executes the blockchain data archiving method described in the embodiment of the present application.
  • the embodiments of the present application also provide a computer-readable storage medium, in which executable instructions are stored, and the executable instructions can be loaded by a processor to implement any of the blockchain data archiving methods provided in the embodiments of the present application .
  • the computer-readable storage medium may include: read only memory (ROM, Read Only Memory), random access memory (RAM, Random Access Memory), magnetic disks or optical disks, etc.
  • any of the methods provided in the embodiments of this application can be implemented.
  • the beneficial effects that can be achieved by the blockchain data archiving method are detailed in the previous embodiment.
  • the executable instructions may be in the form of programs, software, software modules, scripts or codes, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and their It can be deployed in any form, including being deployed as an independent program or as a module, component, subroutine or other unit suitable for use in a computing environment.
  • executable instructions may but do not necessarily correspond to files in the file system, and may be stored as part of files that store other programs or data, for example, in a HyperText Markup Language (HTML, HyperText Markup Language) document
  • HTML HyperText Markup Language
  • One or more scripts in are stored in a single file dedicated to the program in question, or in multiple coordinated files (for example, a file storing one or more modules, subroutines, or code parts).
  • executable instructions can be deployed to be executed on one computing device, or on multiple computing devices located in one location, or on multiple computing devices that are distributed in multiple locations and interconnected by a communication network Executed on.

Abstract

一种区块链数据归档方法、装置、电子设备和计算机可读存储介质，该方法包括：第一记账节点与共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度，同步后区块链数据包括状态数据(101)；第一记账节点在状态数据中确定当前交易所需的目标状态数据，并对目标状态数据进行备份(102)；第一记账节点根据备份后的目标状态数据生成同步区块高度的状态数据快照，将状态数据快照、同步区块高度和第一记账节点的签名信息共同作为归档点信息，并发送至第二记账节点(103)；第一记账节点接收第二记账节点针对归档点信息的背书信息(104)；第一记账节点根据背书信息和归档点信息对同步后区块链数据进行归档(105)。

Description

一种区块链数据归档方法、装置和计算机可读存储介质
相关申请的交叉引用
本申请基于申请号为202010329695.3、申请日为2020年04月24日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及通信技术领域，尤其涉及一种区块链数据归档方法、装置、电子设备和计算机可读存储介质。
背景技术
区块链系统是指通过共识的方式将新区块纳入区块链的一系列的节点的集合，近年来，随着区块链技术的发展，区块链系统在交易领域的应用也越来越广泛，例如可以应用于银行及政府等交易场景中。随着区块链系统运行的时间增加，区块链系统中各节点的区块链数据占用的存储空间也会越来越大，导致区块链系统中的节点会出现响应缓慢甚至宕机的情况，对区块链的运行过程带来不良影响。
发明内容
本申请实施例提供一种区块链数据归档方法，用于区块链系统，所述区块链系统包括共识节点、第一记账节点和第二记账节点，所述方法包括：
所述第一记账节点与所述共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度，所述同步后区块链数据包括状态数据；
所述第一记账节点在所述状态数据中确定当前交易所需的目标状态数据，并对所述目标状态数据进行备份；
所述第一记账节点根据备份后的目标状态数据生成所述同步区块高度的状态数据快照，将所述状态数据快照、所述同步区块高度和所述第一记账节点的签名信息共同作为归档点信息，并发送至所述第二记账节点；
所述第一记账节点接收所述第二记账节点针对所述归档点信息的背书信息；
所述第一记账节点根据所述背书信息和所述归档点信息，对所述同步后区块链数据进行归档。
相应的，本申请实施例提供一种区块链数据归档装置，用于区块链系统，所述区块链系统包括共识节点、第一记账节点和第二记账节点，所述装置包括：
同步单元，配置为所述第一记账节点与所述共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度，所述同步后区块链数据包括状态数据；
确定单元，配置为所述第一记账节点在所述状态数据中确定当前交易所需的目标状态数据，并对所述目标状态数据进行备份；
生成单元，配置为所述第一记账节点根据备份后的目标状态数据生成所述同步区块高度的状态数据快照，将所述状态数据快照、所述同步区块高度和所述第一记账节点的签名信息共同作为归档点信息，并发送至所述第二记账节点；
接收单元，配置为所述第一记账节点接收所述第二记账节点针对所述归档点信息的 背书信息；
归档单元，配置为所述第一记账节点根据所述背书信息和所述归档点信息，对所述同步后区块链数据进行归档。
此外，本申请实施例还提供一种电子设备，包括处理器和存储器，所述存储器存储有可执行指令，所述处理器用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的区块链数据归档方法。
此外，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有可执行指令，用于被处理器执行时，实现本申请实施例所提供的区块链数据归档方法。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1A是本申请实施例提供的区块链数据归档系统的结构示意图；
图1B是本申请实施例提供的区块链系统的结构示意图；
图2A是本申请实施例提供的区块链数据归档方法的流程示意图；
图2B是本申请实施例提供的区块链数据归档方法的流程示意图；
图2C是本申请实施例提供的区块链数据归档方法的流程示意图；
图3是本申请实施例提供的子状态数据备份的示意图；
图4是本申请实施例提供的状态数据对应的默克尔树的快照示意图；
图5是本申请实施例提供的第一记账节点的区块链数据归档示意图；
图6是本申请实施例提供的区块链系统中区块链数据归档的流程示意图；
图7是本申请实施例提供的状态数据对应的默克尔树的结构示意图；
图8是本申请实施例提供的第一记账节点构建本地世界状态的流程示意图；
图9是本申请实施例提供的区块链数据归档方法的流程示意图；
图10是本申请实施例提供的第一记账节点获取最新的区块链数据的流程示意图；
图11是本申请实施例提供的区块链数据归档装置的结构示意图；
图12是本申请实施例提供的区块链数据归档装置的结构示意图；
图13是本申请实施例提供的区块链数据归档装置的结构示意图；
图14是本申请实施例提供的区块链数据归档装置的结构示意图；
图15是本申请实施例提供的区块链数据归档装置的结构示意图；
图16是本申请实施例提供的电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。在以下的描述中，所涉及的术语“多个”是指至少两个。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
1)区块链(Blockchain)：是由区块(Block)形成的加密的、链式的交易的存储结构。例如，每个区块的头部既可以包括区块中所有交易的哈希值，同时也包含前一个区块中所有交易的哈希值，从而基于哈希值实现区块中交易的防篡改和防伪造；新产生的交易被填充到区块并经过区块链系统中节点的共识后，会被追加到区块链的尾部从而形成链式的增长。
2)区块链网络(Blockchain Network)：又称区块链系统，指通过共识的方式将新区块纳入区块链的一系列的节点的集合。
3)交易(Transaction)：等同于计算机术语“事务”，交易包括了需要提交到区块链系统执行的操作，并非单指商业语境中的交易，鉴于在区块链技术中约定俗成地使用了“交易”这一术语，本申请实施例遵循了这一习惯。
例如，部署(Deploy)交易用于向区块链系统中的节点安装指定的智能合约并准备好被调用；调用(Invoke)交易用于通过调用智能合约在区块链中追加交易的记录，并对区块链的状态数据库进行操作，包括更新操作(包括增加、删除和修改状态数据库中的键值对)和查询操作(即查询状态数据库中的键值对)。
4)账本(Ledger)：是区块链(也称为账本数据)以及与区块链同步的状态数据库的统称。其中，区块链是以文件系统中的文件的形式来记录交易；状态数据库是以键(Key)值(Value)对的形式来记录区块链中的交易，用于支持对区块链中交易的快速查询，状态数据库又称账本数据库。
5)智能合约(Smart Contracts)：也称为链码(Chaincode)或应用代码，部署在区块链网络的节点中的程序，节点执行接收的交易中所调用的智能合约，来对状态数据库的键值对数据进行更新或查询的操作。
6)共识(Consensus)：是区块链系统中的一个过程，用于在涉及的多个节点之间对区块中的交易达成一致，达成一致的区块将被追加到区块链的尾部，实现共识的机制包括工作量证明(PoW，Proof of Work)、权益证明(PoS，Proof of Stake)以及股份授权证明(DPoS，Delegated Proof-of-Stake)等。
随着区块链系统运行的时间增加，区块链系统中各节点的区块链数据占用的存储空间也会越来越大，对区块链的运行过程带来不良影响。在相关技术提供的方案中，通常是生成节点的账本快照，然后将账本快照存储至专门的分布式存储系统，最后将快照点之前的区块、交易信息和回执等区块数据在节点本地进行删除，以降低对节点本地的存储空间的占用。
在对相关技术的研究和实践过程中，本申请的申请人发现：在生成账本快照时，区块链系统仍然在正常提供交易服务，如果对记账节点的状态数据进行快照读写时还存在交易，快照读写就会与交易产生冲突，导致快照读取失败或者快照读取的数据不准确，生成的状态数据快照也缺乏公信力。因此，在相关技术提供的方案中，区块链数据的归档精度和归档效率低。
本申请实施例提供一种区块链数据归档方法、装置、电子设备和计算机可读存储介质，能够有效提升区块链数据的归档精度和归档效率。其中，该区块链数据归档装置可以集成在电子设备中，该电子设备可以是服务器，也可以是终端等设备。
本申请实施例提供的区块链数据归档方法主要应用于区块链系统中，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。
区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。
平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。
下面说明本申请实施例提供的区块链系统的示例性应用，参见图1A，图1A是本申请实施例提供的区块链数据归档系统100的结构示意图，包括区块链系统200(区块链系统200包括多个节点，图1A中示例性地示出了节点210)以及业务系统400(示例性示出归属于业务系统400的终端410及其图形界面420)，下面分别进行说明。
区块链系统200的类型是灵活多样的，例如可以为公有链、私有链或联盟链中的任意一种。以公有链为例，任何业务系统(或称业务主体)的电子设备例如终端和服务器，都可以在不需要授权的情况下接入区块链系统200；以联盟链为例，业务系统在获得授权后其下辖的电子设备(例如终端/服务器)可以接入区块链系统200，此时，成为区块链系统200中的一类特殊的节点即客户端节点。
区块链系统200接收来自业务系统的客户端节点(为了便于说明，后文以终端410为例)提交的交易，执行交易以更新账本或者查询账本，并在终端410的图形界面420中显示执行交易的各种中间结果或最终结果。可以理解地，对于上文中接收交易并执行交易的区块链系统200而言，具体是指区块链系统200中的原生的节点210，当然，在业务系统的客户端节点具有区块链系统200中原生节点210的功能(例如共识功能、记账功能)时，也可以包括相应的客户端节点。
下文以业务系统接入区块链系统为例，说明区块链系统的示例性应用。
参见图1A，终端410在需要将数据上传至区块链时，可以生成对应更新操作的交易，该交易包括需要上传的数据。此外，交易中还可以指定实现更新操作需要调用的智能合约、以及向智能合约传递的参数，交易还可以携带业务系统400签署的数字签名(例如，使用认证中心300为业务系统400颁发的数字证书中的私钥，对交易的摘 要进行加密得到)，并将交易广播到区块链系统200。
区块链系统200中的节点210接收到交易时，对交易携带的数字签名进行验证。节点210在对交易中的数字签名验证成功时，根据交易携带的业务系统400的身份，确认业务系统400是否是具有交易权限，数字签名和权限验证中的任何一个验证判断都将导致交易失败。验证成功后，签署节点210自己的数字签名(例如，使用节点210的私钥对交易的摘要进行加密得到)，并继续在区块链系统200中广播。其中，数字签名即签名信息。
区块链系统200中具有排序功能的节点210接收到验证成功的交易后，将交易填充到新的区块中，并广播到区块链系统中200提供共识服务的节点(即共识节点)。
区块链系统200中的提供共识服务的节点210对新区块进行共识过程以达成一致，提供记账功能的节点210(即记账节点)将新区块追加到区块链的尾部，并执行新区块中的交易：对于提交数据的交易，在状态数据库中添加该数据对应的键值对，以实现对状态数据库的更新。值得说明的是，区块链系统中的一个节点可以同时提供多种功能，例如同时提供排序功能和共识功能。
同理，终端410在需要从区块链系统200中查询数据时，可以生成对应查询操作的交易(例如交易可以包括待查询的键)，在交易中指定实现查询操作需要调用的智能合约、以及向智能合约传递的参数，交易还可以携带业务系统400签署的数字签名，并将交易广播到区块链系统200。
区块链系统200中的节点210经过验证、区块填充及共识一致后，将新区块追加到区块链的尾部，并执行新区块中的交易：对于查询数据的交易，从状态数据库中查询对应的键值对，并返回查询结果(例如查询结果可以是与提交的交易中的键对应的值)。
在本申请实施例中，区块链系统可以包括共识节点和多个记账节点。记账节点可以负责通过执行链码实现对账本的读写操作，即主要负责维护状态数据和账本的副本，记账节点也可以称为Peer节点。共识节点也可以称为共识排序节点(Orderer)，在区块链系统中主要用于接收包含签名信息的交易，对未打包的交易进行排序生成区块，并广播给Peer节点，区块链系统包括的共识节点的数量可以仅为一个，当然区块链系统也可以包括共识节点的节点集群。在本申请实施例中，为了描述方便，将需要进行归档操作的记账节点称为第一记账节点，将其他记账节点称为第二记账节点，其中，第二记账节点的数量为至少一个。
例如，参见图1B所示的区块链系统的结构示意图，区块链系统500包括第一记账节点510、第二记账节点520以及共识节点530。第一记账节点510可以与共识节点530进行区块链数据同步，并确定同步后区块链数据的同步区块高度，该同步后区块链数据包括状态数据。然后，第一记账节点510在状态数据中确定当前交易所需的目标状态数据，并对目标状态数据进行备份，其中，当前交易是区块链数据同步后进行的交易。第一记账节点510根据备份后的目标状态数据生成同步区块高度的状态数据快照，将状态数据快照、同步区块高度和第一记账节点510的签名信息共同作为归档点信息，并将归档点信息发送至第二记账节点520。第一记账节点510接收第二记账节点520针对归档点信息的背书信息，该背书信息用于指示第二记账节点520对归档点信息的认可。最终，第一记账节点510根据背书信息和归档点信息，对同步后区块链数据进行归档。
其中，区块链数据可以包括区块链中的区块数据和描述世界状态(World State)的状态数据，其中区块数据是实际在区块链上发生的每一笔交易的记录，区块数据又可以包括普通区块数据和配置区块数据。状态数据可以包括记录了每个账户和智能合约的当前状态，节点的状态数据可以存储于节点的状态数据库(即本地数据库)中。
其中，归档可以理解为数据归档，主要指的是对区块链数据中的一些数据进行拷贝， 得到快照，还可以指对一定范围内的区块数据进行删除和/或转存至其他分布式存储系统(指区别于区块链系统的分布式存储系统，专用于归档)的冷存储中，以节省记账节点本地的存储空间。
在本申请实施例中，区块链系统中的节点(如记账节点及共识节点等)可以是服务器或者终端，客户端节点同理。其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、网络加速服务(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例在此不做限制。
下文将结合本申请实施例提供的区块链系统的示例性应用和实施，说明本申请实施例提供的区块链数据归档方法。需要说明的是，以下实施例的描述顺序不作为对实施例优选顺序的限定。
本申请实施例将从区块链数据归档装置的角度进行描述，该区块链数据归档装置可以集成在电子设备中，该电子设备可以是服务器，也可以是终端等设备。
参见图2A，图2A是本申请实施例提供的区块链数据归档方法的一个流程示意图，将结合图2A示出的步骤进行说明。
在步骤101中，第一记账节点与共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度，同步后区块链数据包括状态数据。
在本申请实施例中，区块链系统包括共识节点和多个记账节点。记账节点也可以称为Peer节点，用于负责通过执行链码实现对账本的读写操作，即主要负责维护状态数据和账本的副本。共识节点用于接收包含签名信息的交易，对未打包的交易进行排序生成区块，并广播给Peer节点。在本申请实施例中，为了描述方便，将需要进行数据归档的记账节点称为第一记账节点，将其他记账节点称为第二记账节点，其中第二记账节点的数量为至少一个。
第一记账节点在需要进行数据归档时，首先与共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度。其中，同步后区块链数据包括区块数据以及状态数据，区块数据用于描述区块链中的区块，状态数据可以包括记录了区块链系统中每个账户和智能合约的当前状态。
其中，同步区块高度可以是指第一记账节点与共识节点进行区块链数据同步后，得到的同步后区块链数据的区块高度(或称区块数量)。比如，第一记账节点的同步后区块链数据中存在5个区块，则同步区块高度就可以为5。
在一些实施例中，可以通过这样的方式来实现上述的第一记账节点与共识节点进行区块链数据同步：第一记账节点向共识节点发送同步请求，同步请求包括第一记账节点的身份标识；第一记账节点接收共识节点针对同步请求发送的区块；其中，区块是共识节点对同步请求中的第一记账节点的身份标识校验通过时发送的；第一记账节点根据共识节点发送的区块，对本地的区块链数据进行更新，得到同步后区块链数据。
例如，第一记账节点可以向共识节点发送同步请求，该同步请求中可以携带第一记账节点的身份标识。共识节点在接收到同步请求时，对同步请求中的第一记账节点的身份标识进行校验。当共识节点对第一记账节点的身份标识校验通过，即确定第一记账节点的身份没有问题时，将共识节点本地存储的区块发送至第一记账节点。这里，共识节点可以将本地存储的所有区块发送至第一记账节点，也可以将最新的区块发送至第一记账节点，以节省计算资源，其中，最新的区块可以是指最新追加至区块链尾部的、且数 量等于同步数量阈值(如1个或2个)的区块，也可以是指在上一次同步(即共识节点上一次向第一记账节点发送区块)的基础上新增的区块。为了便于理解，后文以共识节点将最新的区块发送至第一记账节点为例进行说明。
第一记账节点从共识节点接收到最新的区块后，根据接收到的最新的区块，对本地的区块链数据进行更新，将更新后的区块链数据作为同步后区块链数据，完成区块链数据同步。第一记账节点在同步后区块链数据中识别出存在的区块数量，将该区块数量作为同步后区块链数据的同步区块高度。比如，同步后区块链数据中包含5个区块，则同步后区块链数据的同步区块高度为5。
其中，第一记账节点可以在接收到归档请求或归档指令(例如，人为触发的归档请求或归档指令)时，触发同步请求(指向共识节点发送同步请求)。第一记账节点也可以每隔固定的时间段，自动触发同步请求的发送，比如，第一记账节点可以设定每隔5分钟或每隔20分钟等时间段就触发一次同步请求，然后确定同步后区块链数据的同步区块高度。
在步骤102中，第一记账节点在状态数据中确定当前交易所需的目标状态数据，并对目标状态数据进行备份。
在区块链数据同步之后，区块链系统中的节点可能还在进行交易，如果忽略这些交易，会导致数据归档的准确性降低。因此，在本申请实施例中，第一记账节点在同步后区块链数据包括的状态数据中，确定当前交易所需的目标状态数据，并对目标状态数据进行备份，其中，当前交易是区块链数据同步后进行的交易。
值得说明的是，若是不存在当前交易，或者状态数据中不存在当前交易所需的目标状态数据，则第一记账节点可以直接对同步后区块链数据进行归档，此时能够保证数据归档的准确性。
在一些实施例中，可以通过这样的方式来实现上述的第一记账节点在状态数据中确定当前交易所需的目标状态数据：第一记账节点将同步区块高度与归档区块高度进行匹配；当同步区块高度与归档区块高度匹配成功时，第一记账节点在状态数据中确定当前交易所需的目标状态数据。
这里，为了避免无意义或用处较小的多次数据归档所带来的计算资源的浪费，可以为数据归档预先设定条件。举例来说，可以预先设定归档区块高度，第一记账节点在得到同步区块高度后，将同步区块高度与归档区块高度进行匹配。当同步区块高度与归档区块高度匹配成功时，第一记账节点执行在状态数据中确定当前交易所需的目标状态数据的操作；当同步区块高度与归档区块高度匹配失败时，第一记账节点不再执行后续操作。
归档区块高度可以根据实际应用场景进行设定，其数量可以为一个，也可以为多个。例如，可以设定间隔相同的多个归档区块高度，如10的整数倍，具体包括10、20、…10×n，其中n为大于1的整数。在归档区块高度的数量仅为一个的情况下，“同步区块高度与归档区块高度匹配成功”可以是指同步区块高度与归档区块高度相同，“同步区块高度与归档区块高度匹配失败”可以是指同步区块高度与归档区块高度不同；在归档区块高度的数量包括多个的情况下，“同步区块高度与归档区块高度匹配成功”可以是指同步区块高度与某一个归档区块高度相同，“同步区块高度与归档区块高度匹配失败”可以是指同步区块高度与所有归档区块高度均不同。通过上述方式，能够保证数据归档的必要性，节省计算资源，避免无意义或用处较小的数据归档。
在步骤103中，第一记账节点根据备份后的目标状态数据生成同步区块高度的状态数据快照，将状态数据快照、同步区块高度和第一记账节点的签名信息共同作为归档点信息，并发送至第二记账节点。
其中，状态数据快照可以为对状态数据(这里指备份后的目标状态数据)进行快照拷贝所得到的快照。
第一记账节点可以将状态数据快照、同步区块高度和第一记账节点的签名信息打包成归档点信息，并将归档点信息发送至第二记账节点。其中，第一记账节点可以对状态数据快照进行签名，得到签名信息。
在步骤104中，第一记账节点接收第二记账节点针对归档点信息的背书信息。
其中，背书信息用于指示第二记账节点对归档点信息的认可。第二记账节点可以对接收到的归档点信息进行校验，并在校验通过时对归档点信息进行签名，得到背书信息。
举例来说，第二记账节点可以对第一记账节点发送的归档点信息中的状态数据快照的根哈希值进行校验。当第一记账节点的状态数据快照的根哈希值与第二记账节点自身的状态数据快照的根哈希值相同(即校验通过)时，第二记账节点就对该归档点信息认可，并对归档点信息进行签名，得到针对归档点信息的背书信息，同时，第二记账节点还可以将归档点信息向其他第二记账节点进行广播。
在一些实施例中，在任意步骤之间，还包括：当第一记账节点接收到第二记账节点发送的归档点信息时，第一记账节点从归档点信息中提取出第二记账节点的状态数据的根哈希值；第一记账节点将第二记账节点的状态数据的根哈希值与第一记账节点自身状态数据的根哈希值进行对比；当第二记账节点的状态数据的根哈希值与第一记账节点自身状态数据的根哈希值相同时，第一记账节点对归档点信息进行签名，得到归档点信息的背书信息；第一记账节点将背书信息发送至第二记账节点，并将归档点信息在区块链系统中进行广播。
这里，第一记账节点也可能接收到需要数据归档的第二记账节点所发送的归档点信息。在该情况下，第一记账节点从第二记账节点发送的归档点信息中提取出第二记账节点的状态数据的根哈希值，并将提取出的根哈希值与第一记账节点自身状态数据的根哈希值进行对比，将在后文阐述根哈希值的生成方式。当第二记账节点的状态数据的根哈希值与第一记账节点自身状态数据的根哈希值相同时，第一记账节点对第二记账节点发送的归档点信息进行签名，得到该归档点信息的背书信息，并将背书信息发送至第二记账节点，同时还可以将第二记账节点发送的归档点信息在区块链系统中进行广播。通过上述方式，提升了背书的准确性和有效性。
105、第一记账节点根据背书信息和归档点信息，对同步后区块链数据进行归档。
例如，第一记账节点可以根据背书信息和归档点信息，确定同步后区块链数据中需要删除的目标区块数据，并对目标区块数据进行删除处理，同时，将目标区块数据存储至专用于归档的分布式存储系统中，这里的分布式存储系统区别于区块链系统。
如图2A所示，本申请实施例通过备份当前交易所需的目标状态数据，并基于备份后的目标状态数据生成状态数据快照，解决了快照和原有交易的冲突问题，实现了对状态数据的实时快照；同时，让区块链系统中的其他记账节点针对状态数据快照等信息进行签名背书，使得这些信息具有公信力，因此，可以大大提升区块链数据归档的归档效率和归档准确性。
在一些实施例中，参见图2B，图2B是本申请实施例提供的区块链数据归档方法的一个流程示意图，图2A示出的步骤102可以通过步骤201至步骤204实现，将结合各步骤进行说明。
在步骤201中，第一记账节点获取子状态数据对应的区块高度和在本地数据库中的存储标签。
这里，状态数据可以包括多个子状态数据，这些子状态数据存储在第一记账节点的本地数据库(即状态数据库)。
其中，存储标签可以是指本地数据库中的键值对K-V(key-value)，每一个K(键)对应一个V(值)。比如，某一个子状态数据在本地数据库中的存储标签就可以为K1-V1，K1为该子状态数据在本地数据库中的编号，V1为这个编号在本地数据库中对应的值。
不同的子状态数据可能对应不同的区块高度，第一记账节点根据子状态数据对应的区块编号，可以确定子状态数据对应的区块高度。比如，第一子状态数据对应的是第一区块(指区块链中的第一个区块，后文同理)，就可以说明第一子状态数据对应的区块高度为1；第二子状态数据对应的第三区块，就可以说明第二子状态数据对应的区块高度为3。第一记账节点可以在本地数据库中读取出每一个子状态数据对应的键值对，将该键值对作为子状态数据的存储标签。
在步骤202中，第一记账节点将子状态数据对应的区块高度，添加至子状态数据对应的存储标签以进行标记，得到标记后存储标签。
例如，第一记账节点将子状态数据对应的区块高度，添加至该子状态数据对应的存储标签中，以对该存储标签进行标记。比如，第一记账节点可以在子状态数据的存储标签中添加一个版本号(Version)，该版本号为这个子状态数据对应的区块高度。举例来说，某个子状态数据对应的区块高度为5，存储标签为(K1-V1)，则对存储标签添加版本号(区块高度)进行标记后，标记后存储标签就可以为(K1-V1，版本(5))。
在步骤203中，第一记账节点根据标记后存储标签，在多个子状态数据中筛选出当前交易所需的目标子状态数据。
在一些实施例中，可以通过这样的方式来实现上述的第一记账节点根据标记后存储标签，在多个子状态数据中筛选出当前交易所需的目标子状态数据：第一记账节点获取当前交易对应的交易信息；第一记账节点根据交易信息，确定第一记账节点的当前区块链数据的当前区块高度；当当前区块高度超过同步区块高度时，第一记账节点确定在当前区块链数据中存在新区块；第一记账节点在当前区块链数据中筛选出新区块中的交易需要的调用信息，调用信息用于指示调用的子状态数据；第一记账节点根据调用信息和标记后存储标签，在多个子状态数据中筛选出目标子状态数据。
例如，在进行区块链数据同步后，如果当前交易中还存在交易信息，就意味着此时区块链系统中的记账节点还在进行交易，因此，第一记账节点就会接收共识节点发送的新区块，此时，第一记账节点可以根据当前区块链数据确定当前区块高度。在此需要说明的是，当前区块链数据并不一定是同步后区块链数据，当前区块链数据是在区块链数据同步后继续产生交易，从而对同步后区块链数据进行更新得到的区块链数据。因此，当前区块链数据与同步后区块链数据的区块高度就有可能不一样。如果当前交易中不存在交易信息(等同于不存在当前交易)，就意味此时的当前区块链数据就等于同步后区块链数据。
当当前区块高度超过同步区块高度时，第一记账节点就确定在当前区块链数据中存在新区块，并在当前区块链数据中筛选出新区块中交易需要的调用信息，调用信息用于指示调用的子状态数据。比如，调用信息可以用于指示当前交易需要调用状态数据中的哪个区块高度的哪些子状态数据，譬如，需要调用区块高度为3、子状态数据值为V1的子状态数据。第一记账节点根据调用信息确定需要调用的子状态数据的标记后存储标签，根据确定的标记后存储标签在状态数据中筛选出目标子状态数据，比如，还是以调用信息用于指示需要调用区块高度为3、子状态数据值为V1的子状态数据为例，第一记账节点就可以确定需要调用的目标子状态数据的标记后存储标签为(K1-V1，版本(3))，第一记账节点根据这个标记后存储标签，可以在状态数据中筛选出目标子状态数据。其中，目标状态数据即包括这里筛选出的所有目标子状态数据。通过上述方式，能够提升筛选目标子状态数据的准确性。
值得说明的是，当当前区块高度未超过同步区块高度时，第一记账节点可以停止执行后续操作，即停止数据归档。
在步骤204中，第一记账节点对目标子状态数据进行备份。
第一记账节点在筛选得到目标子状态数据后，即可对目标子状态数据进行备份。
在一些实施例中，可以通过这样的方式实现上述的第一记账节点对目标子状态数据进行备份：第一记账节点在交易信息中筛选出新区块中的交易需要的交易操作信息；第一记账节点根据交易操作信息，确定目标子状态数据对应的交易操作类型；当交易操作类型为更新操作时，第一记账节点将更新操作对应的目标子状态数据进行备份；当交易操作类型为删除操作时，第一记账节点将删除操作对应的目标子状态数据进行备份，并对备份后的目标子状态数据添加删除标签；其中，删除标签用于指示备份后的目标子状态数据在交易执行时不能被读取。
例如，第一记账节点可以在当前区块链数据的交易信息中筛选出新区块中的交易需要的交易操作信息，交易操作信息中包含了交易过程中调用的这些目标子状态数据的操作类型，通常操作类型可以包括更新及删除等。第一记账节点根据交易操作信息，确定目标子状态数据对应的交易操作类型，比如，将交易操作信息中的各个目标子状态数据的交易操作类型进行一一对应，最后，得到每一个目标子状态数据对应的交易操作类型。
第一记账节点根据目标子状态数据的交易操作类型来备份目标子状态数据，如图3所示，当目标子状态数据的交易操作类型为更新操作时，将更新操作对应的目标子状态数据直接进行备份，比如，更新操作对应的目标子状态数据的标记后存储标签为(K1-V1，版本(5))，则直接将这个子状态数据进行备份即可。值得说明的是，图3中的新区块的区块高度即是指当前区块高度。
当目标子状态数据的交易操作类型为删除操作时，第一记账节点对删除操作对应的目标子状态数据进行备份，并对备份后的目标子状态数据添加删除标签，比如，图3中以删除操作对应的目标子状态数据的标记后存储标签为(K3-V3，版本(4))为例，第一记账节点就直接对这个目标子状态数据进行备份，并为这个备份后的目标子状态数据添加一个删除标签。其中，删除标签可以为任意标识，譬如，可以为deleted、D，可以为中文字符“删除”，还可以为其他的删除标识符。对备份后的目标子状态数据添加删除标签，可以是指将删除标签添加至该备份后的目标子状态数据对应的标记后存储标签中，以实现对标记后存储标签的更新。以中文字符“删除”为例，则备份后的目标子状态数据对应的标记后存储标签可以更新为(K3-V3，版本(4)，删除)。第一记账节点对备份后的目标子状态数据添加删除标签之后，就会使得该备份后的目标子状态数据在后续交易时不能被读取。通过上述方式，根据目标子状态数据对应的交易操作类型的不同，采用不同的方式进行备份，提升了备份的有效性和准确性。
在图2B中，图2A示出的步骤103可以通过步骤205至步骤209实现，将结合各步骤进行说明。
在步骤205中，第一记账节点在状态数据中筛选出区块高度不超过同步区块高度的同步子状态数据，得到同步子状态数据集合。
例如，第一记账节点根据状态数据中子状态数据的标记后存储标签，将区块高度不超过同步区块高度的子状态数据筛选出来，为了便于区分，将这里筛选出的子状态数据命名为同步子状态数据。以同步区块高度为5举例，则第一记账节点可以在本地数据库中，筛选出标记后存储标签中的区块高度不超过5的子状态数据，将这些筛选出来的子状态数据作为同步子状态数据，并添加至同步子状态数据集合中。
在步骤206中，第一记账节点将备份后的目标子状态数据作为新的同步子状态数据，并添加至同步子状态数据集合，以更新同步子状态数据集合。
受到新区块中交易(即当前交易)的影响，第一记账节点的状态数据中的、与更新操作对应的目标子状态数据有可能已经被更新，即步骤205得到的同步子状态数据集合包括的是已经被更新的目标子状态数据；第一记账节点的状态数据中的、与删除操作对应的目标子状态数据有可能已经被删除，即步骤205得到的同步子状态数据集合未包括删除操作对应的目标子状态数据。因此，在本申请实施例中，为了保证同步子状态数据集合的数据完整性和准确性，第一记账节点将备份后的目标子状态数据作为新的同步子状态数据，并添加至同步子状态数据集合中，以实现对同步子状态数据集合的更新。
由于备份后的目标状态数据可能包含备份的更新操作对应的目标子状态数据、以及添加删除标签的备份后的目标子状态数据，因此，针对这两种情况进行分别说明。
1)对于更新操作对应的目标子状态数据，第一记账节点利用备份后的更新操作对应的目标子状态数据，对同步子状态数据集合中对应的同步子状态数据进行替换。比如，以更新操作对应的目标子状态数据为(K1-V1，版本(5))举例，在新区块的交易中被更新为(K1-V1’，版本(5+1))，在步骤205得到的同步子状态数据集合包括的也是(K1-V1’，版本(5+1))。此时，第一记账节点利用先前备份的(K1-V1，版本(5))，对同步子状态数据集合中的(K1-V1’，版本(5+1))进行替换，如此就可以保证后续生成的状态数据快照的准确性。
2)对于删除操作对应的目标子状态数据，以(K3-V3，版本(4))举例，由于(K3-V3，版本(4))已经在当前交易的过程中被删除，故步骤205得到的同步后子状态数据集合并不包括(K3-V3，版本(4))。因此，将这个添加删除标签的备份后的目标子状态数据，即(K3-V3，版本(4))添加至同步子状态数据集合中，用于补充被删除的(K3-V3，版本(4))的位置。
值得说明的是，在上述示例中，以标记后存储标签来表示相应的子状态数据。上述方式通过替换和添加的操作，就可以得到更新后的同步子状态数据集合，如此，在区块链数据同步后无论怎么交易，第一记账节点可以保证同步区块高度以内的状态数据的完整性，进一步地，可以保证在对状态数据作快照时，得到的同步区块高度的状态数据快照的准确性。
在步骤207中，第一记账节点对更新后的同步子状态数据集合中的同步子状态数据进行哈希运算，以生成目标结构的状态数据。
例如，目标结构可以是默克尔树(Merkle Tree)，当然这并不构成对本申请实施例的限定。
在一些实施例中，可以通过这样的方式来实现上述的第一记账节点对更新后的同步子状态数据集合中的同步子状态数据进行哈希运算，以生成目标结构的状态数据：第一记账节点对更新后的同步子状态数据集合中的多个同步子状态数据进行分类，得到多个类型的同步子状态数据；第一记账节点对多个类型的同步子状态数据分别进行哈希运算，得到多个类型的同步子状态数据分别对应的叶哈希值；第一记账节点根据多个类型的同步子状态数据分别对应的叶哈希值进行哈希运算，得到根哈希值；第一记账节点根据根哈希值以及多个类型的同步子状态数据分别对应的叶哈希值，生成目标结构的状态数据。
作为示例，本申请实施例提供了如图4所示的目标结构的状态数据的示意图，以更新后的同步子状态数据集合包括10个同步子状态数据，即(K1-V1)至(K10-V10)为例进行说明。首先，第一记账节点可以将同步子状态数据集合中的所有同步子状态数据进行分类，例如，可以按照存储标签(或标记后存储标签)中的键的设定顺序进行分类，并限定每一个类型包括的同步子状态数据的数量不超过类型数量阈值，其中，键的设定顺序可以是从小到大的顺序或从大到小的顺序，类型数量阈值可以根据实际应用场景进行设定，如设定为3。
譬如，在图4中，可以将(K1-V1)、(K2-V2)和(K3-V3)分为第一类，将(K4-V4)、(K5-V5)和(K6-V6)分为第二类，将(K7-V7)、(K8-V8)和(K9-V9)分为第三类，将(K10-V10)单独作为第四类。在完成分类后，单独对每个类型的同步子状态数据进行哈希运算，得到每个类型对应的哈希值，例如对(K1-V1)、(K2-V2)和(K3-V3)进行哈希运算得到哈希值h1，对(K4-V4)、(K5-V5)和(K6-V6)进行哈希运算得到哈希值h2，以此类推。然后，再对h1和h2进行哈希运算，得到中间哈希值h5；对h3和h4进行哈希运算，得到中间哈希值h6。最终对中间哈希值h5和h6进行哈希运算，得到根哈希值h7。根据计算出的这些哈希值，生成目标结构的状态数据，比如，可以根据这些哈希值，构建一个默克尔树，将四个类型分别对应的哈希值h1、h2、h3和h4作为默克尔树的叶哈希值，将h5和h6作为默克尔树的中间哈希值，将h7作为默克尔树的根哈希值(Root Hash)。
在步骤208中，第一记账节点对目标结构的状态数据进行拷贝，以生成同步区块高度的状态数据快照。
这里，第一记账节点对生成的目标结构的状态数据进行拷贝，得到同步区块高度的状态数据快照。比如，可以对生成的默克尔树的状态进行拷贝，得到默克尔树的快照，如图4所示。
在步骤209中，第一记账节点将状态数据快照、同步区块高度和第一记账节点的签名信息共同作为归档点信息，并发送至第二记账节点。
例如，第一记账节点对状态数据快照进行签名，得到签名信息。然后，第一记账节点将签名信息、状态数据快照和同步区块高度打包成归档点信息，并将归档点信息发送至区块链系统的第二记账节点。
如图2B所示，本申请实施例根据标记后存储标签来筛选目标子状态数据，能够提升筛选效率及筛选精度；根据备份后的目标子状态数据对同步子状态数据集合进行更新，能够保证更新后的同步子状态数据集合的数据完整性和数据准确性。
在一些实施例中，参见图2C，图2C是本申请实施例提供的区块链数据归档方法的一个流程示意图，图2A示出的步骤105可以通过步骤301至步骤304实现，将结合各步骤进行说明。
在步骤301中，第一记账节点确定发送背书信息的第二记账节点的背书数量。
例如，第一记账节点根据接收到的背书信息，确定发送背书信息的第二记账节点的数量，以作为背书数量。比如，第一记账节点接收到了5个背书信息，就可以确定发送背书信息的第二记账节点的数量为5，即背书数量为5。
在步骤302中，当背书数量超过数量阈值时，第一记账节点将背书信息添加至归档点信息中，得到更新后归档点信息。
这里，数量阈值可以根据实际应用场景进行设定，例如可以是区块链系统包括的第二记账节点的总数的1/2、1/3、或者其他比例对应的数量，还可以直接设定为3个、5个或者7个等数值。当发送背书信息的第二记账节点的数量超过数量阈值时，第一记账节点将背书信息添加至归档点信息中，以对归档点信息进行更新，得到更新后归档点信息。其中，更新后归档点信息中的背书信息以及第一记账节点的签名信息可以共同组成针对同步区块高度的状态数据的签名证据信息。
在步骤303中，第一记账节点将更新后归档点信息发送至共识节点。
这里，第一记账节点将更新后归档点信息发送至共识节点，共识节点根据更新后归档点信息，确定是否生成配置区块数据。其中，配置区块数据是由共识节点生成配置区块，并将更新后归档点信息存储至配置区块得到的。
在一些实施例中，步骤303之后，还包括：共识节点在更新后归档点信息中筛选出背书信息和签名信息；共识节点对背书信息和签名信息进行校验；当共识节点对背书信息和签名信息校验通过时，共识节点生成配置区块，并将更新后归档点信息存储至配置区块，得到配置区块数据；共识节点将配置区块数据发送至第一记账节点和第二记账节点。
例如，第一记账节点将更新后归档点信息发送至共识节点，共识节点从更新后归档点信息中筛选出背书信息和签名信息，并对背书信息和签名信息进行校验，即对背书信息和第一记账节点的签名信息组成的签名证据信息进行校验。
针对背书信息，共识节点可以对背书信息的数量进行校验，例如当背书信息的数量超过数量阈值(可以与步骤302中的数量阈值相同)时，确定对背书信息校验通过；当背书信息的数量未超过数量阈值时，确定对背书信息校验未通过。共识节点还可以对背书信息对应的第二记账节点的身份标识进行校验，例如当区块链系统中存在与每个背书信息对应的第二记账节点时，确定对背书信息校验通过；当区块链系统中不存在与某个或多个背景信息对应的第二记账节点时，确定对背书信息校验未通过。值得说明的是，在同时对背书信息的数量、以及背书信息对应的第二记账节点的身份标识进行校验的情况下，只有当背书信息的数量超过数量阈值、且区块链系统中存在与每个背书信息对应的第二记账节点时，才确定对背书信息校验通过。
针对第一记账节点的签名信息，共识节点可以根据设定的签名格式以及签名规则中的至少之一，对第一记账节点的签名信息进行校验。以签名格式为例，当第一记账节点的签名信息符合签名格式时，确定对该签名信息校验通过；当第一记账节点的签名信息不符合签名格式时，确定对该签名信息校验未通过。根据签名规则进行的校验过程同理。值得说明的是，在根据签名格式以及签名规则对第一记账节点的签名信息进行校验的情况下，只有当第一记账节点的签名信息同时符合签名格式以及签名规则时，才确定对该签名信息校验通过。
共识节点对背书信息和签名信息的校验规则并不限于上述示例，可以根据实际应用场景来进行设定，例如可以根据特定的背书规则或背书要求对背书信息进行校验。当共识节点对背书信息和签名信息校验通过时，共识节点生成配置区块，并将更新后归档点信息存储至配置区块，得到配置区块数据。然后，共识节点将配置区块数据发送至第一记账节点和第二记账节点。通过上述方式，实现了对更新后归档点信息的有效校验，提升了数据归档的合法性，有效避免了恶意归档。
在步骤304中，当第一记账节点接收到共识节点针对更新后归档点信息发送的配置区块数据时，第一记账节点对同步后区块链数据进行归档。
这里，当第一记账节点接收到共识节点针对更新后归档点信息发送的配置区块数据时，证明共识节点已经认可更新后归档点信息，故第一记账节点对同步后区块链数据进行归档。
在一些实施例中，可以通过这样的方式来实现上述的第一记账节点对同步后区块链数据进行归档：第一记账节点对更新后归档点信息进行拷贝，以生成第一记账节点在同步区块高度的归档数据快照；第一记账节点将配置区块数据添加至第一区块数据中，得到更新后第一区块数据；第一记账节点在更新后第一区块数据中筛选出区块高度未超过同步区块高度的目标区块数据；第一记账节点将目标区块数据进行删除。
例如，第一记账节点对更新后归档信息中的同步区块高度、签名信息和背书信息进行拷贝，得到这些数据对应的数据快照，然后将这些数据对应的数据快照和更新后归档信息中的状态数据快照共同构成同步区块高度的归档数据快照，并将归档数据快照存储在本地。
同时，第一记账节点将配置区块数据添加至第一区块数据中，以对第一区块数据进行更新，得到更新后第一区块数据，其中，第一区块数据是指同步后区块链数据包括的区块。第一记账节点在更新后第一区块数据中筛选出区块高度未超过同步区块高度的区块数据，为了便于区分，将这里筛选出的区块数据命名为目标区块数据。作为示例，本申请实施例提供了如图5所示的数据归档的示意图，以同步区块高度为H举例，在更新后第一区块数据中筛选出普通区块数据，并在筛选出的普通区块数据中进一步筛选出区块高度未超过H的普通区块，以作为目标区块数据，在图5中示出了目标区块数据包括普通区块0至普通区块H。其中，普通区块数据是指更新后第一区块数据中区别于配置区块数据的区块数据，另外，图5中的H为大于或等于0的整数，N为大于H的整数。在得到目标区块数据后，第一记账节点可以对目标区块数据进行删除处理，如图5所示，第一记账节点删除普通区块0至普通区块H。
在一些实施例中，步骤303之后，还包括：当第二记账节点接收到共识节点发送的配置区块数据时，第二记账节点对配置区块数据中的签名信息、背书信息、状态数据快照和同步区块高度进行拷贝，得到同步区块高度的归档数据快照；第二记账节点将配置区块数据添加至第二记账节点的区块链数据中，并在更新后的第二记账节点的区块链数据中筛选出区块高度未超过同步区块高度的目标区块数据；第二记账节点将目标区块数据进行删除。
共识节点在生成配置区块数据后，将配置区块数据发送至第一记账节点和第二记账节点。当第二记账节点接收到配置区块数据时，第二记账节点提取出配置区块数据中的签名信息、背书信息、状态数据快照和同步区块高度，对提取出的这些数据进行拷贝得到同步区块高度的归档数据快照，并将该归档数据快照存储至本地。
同时，第二记账节点还可以将配置区块数据添加至第二记账节点本地的区块链数据中，得到更新后的第二记账节点的区块链数据。然后，第二记账节点在更新后的第二记账节点的区块链数据中筛选出区块高度未超过同步区块高度的目标区块数据(为了便于区分，命名为第二记账节点的目标区块数据)，并将第二记账节点的目标区块数据进行删除，完成数据归档。通过上述方式，在第一记账节点进行数据归档的同时，也可以实现第二记账节点的数据归档，从而节省区块链系统中所有记账节点的存储资源。
其中，第一记账节点和第二记账节点对未超过同步区块高度的目标区块数据进行归档的过程可以是同时进行的，也可以是不同时进行的。整个归档过程可以如图6所示，图6中的归档共识是指共识节点在数据归档过程中执行的操作。值得说明的是，在数据归档过程中，还可以将目标区块数据存储至分布式存储系统中，其中，分布式存储系统区别于区块链系统，分布式存储系统可以用于进行冷存储(Cold Storage)，即存储的数据不常被访问；区块链系统可以用于热存储(Hot Storage)，即存储的数据经常被访问。
在一些实施例中，在任意步骤之间，还包括：当第一记账节点为区块链系统中新增的记账节点时，第一记账节点向共识节点发送同步请求，并接收共识节点针对同步请求发送的背书信息和归档点信息；第一记账节点根据背书信息和归档点信息，从第二记账节点获取状态数据；第一记账节点从共识节点或第二记账节点获取区块高度超过同步区块高度的第二区块数据；第一记账节点根据第二区块数据中的交易信息，对状态数据进行更新，得到第一记账节点的当前区块链数据。
当第一记账节点为区块链系统中新增的记账节点时，第一记账节点需要从区块链系统中获取在本地存储的区块链数据，即在本申请实施例中除了数据归档的需求外，还存在数据获取的需求。
面临数据获取的需求，第一记账节点可以向共识节点发送同步请求，共识节点在接收到同步请求时，向第一记账节点发送针对该同步请求的背书信息和归档点信息。第一 记账节点根据接收到的背书信息和归档点信息，从第二记账节点获取状态数据。第一记账节点还可以从共识节点或第二记账节点获取区块高度超过同步区块高度的区块数据，为了便于区分，将这里获取到的区块数据命名为第二区块数据，这里的同步区块高度可以是指第二记账节点进行区块链数据同步后得到的同步区块高度。例如，当同步区块高度为5时，则第一记账节点从共识节点或第二记账节点获取区块高度超过5的区块数据，以作为第二区块数据。然后，第一记账节点根据第二区块数据中的交易信息对状态数据进行更新，比如，可以通过回放第二区块数据包括的区块中的交易，对第一记账节点的世界状态进行更新，以同步到共识节点和第二记账节点中最新的世界状态，得到第一记账节点的当前区块链数据。通过上述方式，能够使区块链系统中新增的记账节点得到准确、有效的当前区块链数据，提升数据获取的精度。
在一些实施例中，可以通过这样的方式来实现上述的第一记账节点根据背书信息和归档点信息，从第二记账节点获取状态数据：第一记账节点对背书信息和第二记账节点的签名信息进行校验；当第一记账节点对背书信息和第二记账节点的签名信息校验通过时，第一记账节点确定根哈希值对应的多个叶哈希值；第一记账节点从第二记账节点中并行获取不同叶哈希值对应的子状态数据，以作为得到的状态数据。
这里，第一记账节点在接收到背书信息和归档点信息时，可以对背书信息以及归档点信息中的第二记账节点(这里是指进行数据归档的记账节点)的签名信息进行校验，这里对校验规则不做限定，可以沿用上文中共识节点的校验规则。
当第一记账节点对背书信息以及第二记账节点的签名信息校验通过时，第一记账节点根据归档点信息中的根哈希值，确定对应的多个叶哈希值。其中，第一记账节点接收到的归档点信息包括共识节点的状态数据的根哈希值和第二记账节点的签名信息。比如，以状态数据对应的默克尔树(即目标结构)如图7所示为例，根哈希值为h7，则第一记账节点根据该默克尔树，可以确定出根哈希值对应的叶哈希值包括h1、h2、h3和h4。
在得到多个叶哈希值后，第一记账节点可以从第二记账节点中并行获取不同叶哈希值对应的子状态数据，并将获取到的所有子状态数据共同作为得到的状态数据。其中，第一记账节点可以从单个第二记账节点中获取所有叶哈希值分别对应的子状态数据，也可以从不同的第二记账节点中获取不同的子状态数据。通过上述方式，能够保证获取到的状态数据的准确性。
在一些实施例中，可以通过这样的方式来实现上述的第一记账节点从第二记账节点中并行获取不同叶哈希值对应的子状态数据：第一记账节点根据第二记账节点的数量，对多个叶哈希值进行分类；第一记账节点根据对多个叶哈希值的分类结果，确定不同第二记账节点对应的目标叶哈希值；第一记账节点从不同第二记账节点获取目标叶哈希值对应的子状态数据。
比如，区块链系统中的第二记账节点的数量为2个，则第一记账节点可以将h1和h2分为一类，将h3和h4分为一类。然后，第一记账节点根据分类结果，确定第二记账节点对应的目标叶哈希值，比如，第一记账节点可以将分为一类的h1和h2，均作为第二记账节点A对应的目标叶哈希值，将另一类的h3和h4均作为第二记账节点B对应的目标叶哈希值。
对于每个第二记账节点，第一记账节点根据第二记账节点对应的目标叶哈希值，从该第二记账节点中获取目标叶哈希值对应的子状态数据。如图8所示，第一记账节点可以从第二记账节点A中获取h1对应的子状态数据(K1-V1)至(K3-V3)、以及h2对应的子状态数据(K4-V4)至(K6-V6)，从第二记账节点B中获取h3对应的子状态数据(K7-V7)至(K9-V9)、以及h4对应的子状态数据(K10-V10)。第一记账节点利用得到的状态数据，可以构建第一记账节点本地的世界状态。通过上述方式，从不同的第二 记账节点中获取不同的子状态数据，能够减轻每个第二记账节点的处理压力，同时也可以提升获取到的状态数据的准确性。
如图2C所示，本申请实施例将更新后归档信息发送至共识节点，并在接收到共识节点针对更新后归档信息发送的配置区块数据时，再对同步后区块链数据进行归档，能够有效提升归档的有效性和准确性。
根据上面实施例所描述的方法，以下将举例作进一步详细说明。参见图9，图9是本申请实施例提供的区块链数据归档方法的流程示意图，将结合图9示出的步骤进行说明。
在步骤401中，第一记账节点与共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度。
在步骤402中，当同步区块高度与归档区块高度匹配成功时，第一记账节点获取子状态数据对应的区块高度和在本地数据库中的存储标签。
在步骤403中，第一记账节点将子状态数据对应的区块高度，添加至子状态数据对应的存储标签以进行标记，得到标记后存储标签。
在步骤404中，第一记账节点根据标记后存储标签，在多个子状态数据中筛选出当前交易所需的目标子状态数据。
在步骤405中，第一记账节点对目标子状态数据进行备份。
在步骤406中，第一记账节点根据备份后的目标子状态数据生成同步区块高度的状态数据快照，将状态数据快照、同步区块高度和第一记账节点的签名信息共同作为归档点信息，并发送至第二记账节点。
在步骤407中，第二记账节点生成针对归档点信息的背书信息，并将背书信息发送至第一记账节点。
在步骤408中，第一记账节点接收第二记账节点针对归档点信息的背书信息。
在步骤409中，第一记账节点确定发送背书信息的第二记账节点的背书数量。
在步骤410中，当背书数量超过数量阈值时，第一记账节点将背书信息添加至归档点信息中，得到更新后归档点信息，并将更新后归档点信息发送至共识节点。
在步骤411中，共识节点根据更新后归档点信息生成配置区块数据，并将配置区块数据发送至第一记账节点和第二记账节点。
在步骤412中，当第一记账节点接收到共识节点发送的配置区块数据时，第一记账节点对同步后区块链数据进行归档。
在步骤413中，当第二记账节点接收到配置区块数据时，第二记账节点对第二记账节点的区块链数据进行归档。
在一些实施例中，当第一记账节点为区块链系统中新增的记账节点时，第一记账节点可以从区块链系统中获取最新的区块链数据，将结合图10所示的步骤进行说明。
在步骤414中，第一记账节点将同步请求发送至共识节点。
在步骤415中，共识节点根据同步请求，将背书信息和归档点信息发送至第一记账节点。
在步骤416中，第一记账节点根据背书信息和归档点信息，从第二记账节点获取状态数据。
在步骤417中，第一记账节点从共识节点或第二记账节点获取区块高度超过同步区块高度的第二区块数据。
在步骤418中，第一记账节点根据第二区块数据中的交易信息，对状态数据进行更新，得到第一记账节点的当前区块链数据。
如图9和图10所示，本申请实施例可以备份当前交易所需的目标状态数据，并基 于备份后的目标状态数据生成状态数据快照，解决了快照和原有交易的冲突问题，实现了对状态数据的实时快照；并且，让区块链系统中的其他记账节点针对状态数据快照等信息进行签名背书，使得这些信息具有公信力，因此，可以大大提升区块链数据归档的归档效率和归档精度；此外，除了数据归档之外，本申请实施例针对新增的记账节点，可以通过发送背书信息、归档点信息及第二区块数据等信息，使得新增的记账节点能够得到准确的当前区块链数据，即能够得到简洁、准确的账本。
为了更好地实施以上方法，本申请实施例还提供一种区块链数据归档装置，该区块链数据归档装置可以集成在电子设备，比如服务器或终端等设备中，该终端可以包括平板电脑、笔记本电脑和/或个人计算机等。
例如，如图11所示，该区块链数据归档生成装置可以包括同步单元301、确定单元302、生成单元303、接收单元304和归档单元305。同步单元301，配置为第一记账节点与共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度，同步后区块链数据包括状态数据；确定单元302，配置为第一记账节点在状态数据中确定当前交易所需的目标状态数据，并对目标状态数据进行备份；生成单元303，配置为第一记账节点根据备份后的目标状态数据生成同步区块高度的状态数据快照，将状态数据快照、同步区块高度和第一记账节点的签名信息共同作为归档点信息，并发送至第二记账节点；接收单元304，配置为第一记账节点接收第二记账节点针对归档点信息的背书信息；归档单元305，配置为第一记账节点根据背书信息和归档点信息，对同步后区块链数据进行归档。
在一些实施例中，状态数据包括多个子状态数据，确定单元302可以包括获取子单元3021、添加子单元3022、筛选子单元3023和备份子单元3024，如图12所示。获取子单元3021，配置为第一记账节点获取子状态数据对应的区块高度和在本地数据库中的存储标签；添加子单元3022，配置为第一记账节点将子状态数据对应的区块高度，添加至子状态数据对应的存储标签以进行标记，得到标记后存储标签；筛选子单元3023，配置为第一记账节点根据标记后存储标签，在多个子状态数据中筛选出当前交易所需的目标子状态数据；备份子单元3024，配置为第一记账节点对目标子状态数据进行备份。
在一些实施例中，筛选子单元3023，配置为：第一记账节点获取当前交易对应的交易信息；第一记账节点根据交易信息，确定第一记账节点的当前区块链数据的当前区块高度；当当前区块高度超过同步区块高度时，第一记账节点确定在当前区块链数据中存在新区块；第一记账节点在当前区块链数据中筛选出新区块中的交易需要的调用信息，调用信息用于指示调用的子状态数据；第一记账节点根据调用信息和标记后存储标签，在多个子状态数据中筛选出目标子状态数据。
在一些实施例中，备份子单元3024，配置为：第一记账节点在交易信息中筛选出新区块中的交易需要的交易操作信息；第一记账节点根据交易操作信息，确定目标子状态数据对应的交易操作类型；当交易操作类型为更新操作时，第一记账节点将更新操作对应的目标子状态数据进行备份；当交易操作类型为删除操作时，第一记账节点将删除操作对应的目标子状态数据进行备份，并对备份后的目标子状态数据添加删除标签；其中，删除标签用于指示备份后的目标子状态数据在交易执行时不能被读取。
在一些实施例中，生成单元303，配置为：第一记账节点在状态数据中筛选出区块高度不超过同步区块高度的同步子状态数据，得到同步子状态数据集合；第一记账节点将备份后的目标子状态数据作为新的同步子状态数据，并添加至同步子状态数据集合，以更新同步子状态数据集合；第一记账节点对更新后的同步子状态数据集合中的同步子状态数据进行哈希运算，以生成目标结构的状态数据；第一记账节点对目标结构的状态数据进行拷贝，以生成同步区块高度的状态数据快照。
在一些实施例中，生成单元303，配置为：第一记账节点对更新后的同步子状态数据集合中的多个同步子状态数据进行分类，得到多个类型的同步子状态数据；第一记账节点对多个类型的同步子状态数据分别进行哈希运算，得到多个类型的同步子状态数据分别对应的叶哈希值；第一记账节点根据多个类型的同步子状态数据分别对应的叶哈希值进行哈希运算，得到根哈希值；第一记账节点根据根哈希值以及多个类型的同步子状态数据分别对应的叶哈希值，生成目标结构的状态数据。
在一些实施例中，归档单元305可以包括确定子单元3051、更新子单元3052、发送子单元3053和归档子单元3054，如图13所示。确定子单元3051，配置为第一记账节点确定发送背书信息的第二记账节点的背书数量；更新子单元3052，配置为当背书数量超过数量阈值时，第一记账节点将背书信息添加至归档点信息中，得到更新后归档点信息；发送子单元3053，配置为第一记账节点将更新后归档点信息发送至共识节点；归档子单元3054，配置为当第一记账节点接收到共识节点针对更新后归档点信息发送的配置区块数据时，第一记账节点对同步后区块链数据进行归档。
在一些实施例中，同步后区块链数据包括第一区块数据；归档子单元3054，配置为：第一记账节点对更新后归档点信息进行拷贝，以生成第一记账节点在同步区块高度的归档数据快照；第一记账节点将配置区块数据添加至第一区块数据中，得到更新后第一区块数据；第一记账节点在更新后第一区块数据中筛选出区块高度未超过同步区块高度的目标区块数据；第一记账节点将目标区块数据进行删除。
在一些实施例中，归档子单元3054，配置为：当第一记账节点将目标区块数据进行删除时，第一记账节点将目标区块数据存储至分布式存储系统中；其中，分布式存储系统区别于区块链系统。
在一些实施例中，发送子单元3053，配置为：共识节点在更新后归档点信息中筛选出背书信息和签名信息；共识节点对背书信息和签名信息进行校验；当共识节点对背书信息和签名信息校验通过时，共识节点生成配置区块，并将更新后归档点信息存储至配置区块，得到配置区块数据；共识节点将配置区块数据发送至第一记账节点和第二记账节点。
在一些实施例中，发送子单元3053，配置为：共识节点对背书信息的数量、以及背书信息对应的第二记账节点的身份标识中的至少之一进行校验；共识节点根据签名格式以及签名规则中的至少之一，对签名信息进行校验。
在一些实施例中，区块链数据归档装置还可以包括背书单元306，如图14所示。背书单元306，配置为当第一记账节点接收到第二记账节点发送的归档点信息时，第一记账节点从归档点信息中提取出第二记账节点的状态数据的根哈希值；第一记账节点将第二记账节点的状态数据的根哈希值与第一记账节点自身状态数据的根哈希值进行对比；当第二记账节点的状态数据的根哈希值与第一记账节点自身状态数据的根哈希值相同时，第一记账节点对归档点信息进行签名，得到归档点信息的背书信息；第一记账节点将背书信息发送至第二记账节点，并将归档点信息在区块链系统中进行广播。
在一些实施例中，当第一记账节点为区块链系统中新增的记账节点时，区块链数据归档装置还可以包括更新单元307，如图15所示。更新单元307，配置为第一记账节点向共识节点发送同步请求，并接收共识节点针对同步请求发送的背书信息和归档点信息；第一记账节点根据背书信息和归档点信息，从第二记账节点获取状态数据；第一记账节点从共识节点或第二记账节点获取区块高度超过同步区块高度的第二区块数据；第一记账节点根据第二区块数据中的交易信息，对状态数据进行更新，得到第一记账节点的当前区块链数据。
在一些实施例中，归档点信息包括共识节点的状态数据的根哈希值和第二记账节点的签名信息；更新单元307，配置为：第一记账节点对背书信息和第二记账节点的签名信息进行校验；当第一记账节点对背书信息和第二记账节点的签名信息校验通过时，第一记账节点确定根哈希值对应的多个叶哈希值；第一记账节点从第二记账节点中并行获取不同叶哈希值对应的子状态数据，以作为得到的状态数据。
在一些实施例中，更新单元307，配置为：第一记账节点根据第二记账节点的数量，对多个叶哈希值进行分类；第一记账节点根据对多个叶哈希值的分类结果，确定不同第二记账节点对应的目标叶哈希值；第一记账节点从不同第二记账节点获取目标叶哈希值对应的子状态数据。
在一些实施例中，同步单元301，配置为：第一记账节点向共识节点发送同步请求，同步请求包括第一记账节点的身份标识；第一记账节点接收共识节点针对同步请求发送的区块；其中，区块是共识节点对同步请求中的第一记账节点的身份标识校验通过时发送的；第一记账节点根据共识节点发送的区块，对本地的区块链数据进行更新，得到同步后区块链数据。
在一些实施例中，确定单元302，配置为：第一记账节点将同步区块高度与归档区块高度进行匹配；当同步区块高度与归档区块高度匹配成功时，第一记账节点在状态数据中确定当前交易所需的目标状态数据。
实施时，以上各个单元可以作为独立的实体来实现，也可以进行任意组合，作为同一或若干个实体来实现，以上各个单元的实施可参见前面的方法实施例。
本申请实施例还提供一种电子设备，如图16所示，其示出了本申请实施例所涉及的电子设备的结构示意图，该电子设备可以包括一个或者一个以上处理核心的处理器401、一个或一个以上计算机可读存储介质的存储器402、电源403和输入单元404等部件。本领域技术人员可以理解，图16中示出的电子设备结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
处理器401是该电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器402内的软件程序和/或模块，以及调用存储在存储器402内的数据，执行电子设备的各种功能和处理数据，从而对电子设备进行整体监控。可选的，处理器401可包括一个或多个处理核心；优选的，处理器401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器401中。
存储器402可用于存储软件程序以及模块，处理器401通过运行存储在存储器402的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器402可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备的使用所创建的数据等。此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器402还可以包括存储器控制器，以提供处理器401对存储器402的访问。
电子设备还包括给各个部件供电的电源403，优选的，电源403可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源403还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
该电子设备还可包括输入单元404，该输入单元404可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球 信号输入。
尽管未示出，电子设备还可以包括显示单元等。在本实施例中，电子设备中的处理器401会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序(可执行指令)，从而实现各种功能，如下：
第一记账节点与共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度，同步后区块链数据包括状态数据；第一记账节点在状态数据中确定当前交易所需的目标状态数据，并对目标状态数据进行备份；第一记账节点根据备份后的目标状态数据生成同步区块高度的状态数据快照，将状态数据快照、同步区块高度和第一记账节点的签名信息共同作为归档点信息，并发送至第二记账节点；第一记账节点接收第二记账节点针对归档点信息的背书信息；第一记账节点根据背书信息和归档点信息，对同步后区块链数据进行归档。以上各个操作的实施可参见前面的实施例。
由以上可知，本申请实施例可以备份当前交易所需的目标状态数据，并基于备份后的目标状态数据生成状态数据快照，解决了快照和原有交易的冲突问题，实现了对状态数据的实时快照，而且让区块链中的其他记账节点针对状态数据快照等信息进行签名背书，使得这些信息具有公信力，因此，可以大大提升区块链数据归档的归档效率和归档精度。
本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令(可执行指令)来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。
为此，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括可执行指令，该可执行指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该可执行指令，处理器执行该可执行指令，使得该计算机设备执行本申请实施例上述的区块链数据归档方法。
本申请实施例还提供一种计算机可读存储介质，其中存储有可执行指令，该可执行指令能够被处理器进行加载，以实现本申请实施例所提供的任一种区块链数据归档方法。其中，该计算机可读存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。
由于该计算机可读存储介质中所存储的可执行指令，可以用于执行本申请实施例所提供的任一种区块链数据归档方法，因此，可以实现本申请实施例所提供的任一种区块链数据归档方法所能实现的有益效果，详见前面的实施例。
在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper Text Markup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。
作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
以上对本申请实施例所提供的一种区块链数据归档方法、装置、电子设备和计算机 可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (20)

  1. 一种区块链数据归档方法，用于区块链系统，所述区块链系统包括共识节点、第一记账节点和第二记账节点，所述方法包括：
    所述第一记账节点与所述共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度，所述同步后区块链数据包括状态数据；
    所述第一记账节点在所述状态数据中确定当前交易所需的目标状态数据，并对所述目标状态数据进行备份；
    所述第一记账节点根据备份后的目标状态数据生成所述同步区块高度的状态数据快照，将所述状态数据快照、所述同步区块高度和所述第一记账节点的签名信息共同作为归档点信息，并发送至所述第二记账节点；
    所述第一记账节点接收所述第二记账节点针对所述归档点信息的背书信息；
    所述第一记账节点根据所述背书信息和所述归档点信息，对所述同步后区块链数据进行归档。
  2. 根据权利要求1所述的区块链数据归档方法，其中，所述状态数据包括多个子状态数据；
    所述第一记账节点在所述状态数据中确定当前交易所需的目标状态数据，并对所述目标状态数据进行备份，包括：
    所述第一记账节点获取所述子状态数据对应的区块高度和在本地数据库中的存储标签；
    所述第一记账节点将所述子状态数据对应的区块高度，添加至所述子状态数据对应的存储标签以进行标记，得到标记后存储标签；
    所述第一记账节点根据所述标记后存储标签，在所述多个子状态数据中筛选出当前交易所需的目标子状态数据；
    所述第一记账节点对所述目标子状态数据进行备份。
  3. 根据权利要求2所述的区块链数据归档方法，其中，所述第一记账节点根据所述标记后存储标签，在所述多个子状态数据中筛选出当前交易所需的目标子状态数据，包括：
    所述第一记账节点获取所述当前交易对应的交易信息；
    所述第一记账节点根据所述交易信息，确定所述第一记账节点的当前区块链数据的当前区块高度；
    当所述当前区块高度超过所述同步区块高度时，所述第一记账节点确定在所述当前区块链数据中存在新区块；
    所述第一记账节点在所述当前区块链数据中筛选出所述新区块中的交易需要的调用信息，所述调用信息用于指示调用的所述子状态数据；
    所述第一记账节点根据所述调用信息和所述标记后存储标签，在所述多个子状态数据中筛选出所述目标子状态数据。
  4. 根据权利要求3所述的区块链数据归档方法，其中，所述第一记账节点对所述目标子状态数据进行备份，包括：
    所述第一记账节点在所述交易信息中筛选出所述新区块中的交易需要的交易操作信息；
    所述第一记账节点根据所述交易操作信息，确定所述目标子状态数据对应的交易操作类型；
    当所述交易操作类型为更新操作时，所述第一记账节点将所述更新操作对应的目标子状态数据进行备份；
    当所述交易操作类型为删除操作时，所述第一记账节点将所述删除操作对应的目标子状态数据进行备份，并对备份后的目标子状态数据添加删除标签；
    其中，所述删除标签用于指示所述备份后的目标子状态数据在交易执行时不能被读取。
  5. 根据权利要求2所述的区块链数据归档方法，其中，所述第一记账节点根据备份后的目标状态数据生成所述同步区块高度的状态数据快照，包括：
    所述第一记账节点在所述状态数据中筛选出区块高度不超过所述同步区块高度的同步子状态数据，得到同步子状态数据集合；
    所述第一记账节点将备份后的目标子状态数据作为新的同步子状态数据，并添加至所述同步子状态数据集合，以更新所述同步子状态数据集合；
    所述第一记账节点对更新后的同步子状态数据集合中的同步子状态数据进行哈希运算，以生成目标结构的状态数据；
    所述第一记账节点对所述目标结构的状态数据进行拷贝，以生成所述同步区块高度的状态数据快照。
  6. 根据权利要求5所述的区块链数据归档方法，其中，所述第一记账节点对更新后的同步子状态数据集合中的同步子状态数据进行哈希运算，以生成目标结构的状态数据，包括：
    所述第一记账节点对更新后的同步子状态数据集合中的多个同步子状态数据进行分类，得到多个类型的同步子状态数据；
    所述第一记账节点对所述多个类型的同步子状态数据分别进行哈希运算，得到所述多个类型的同步子状态数据分别对应的叶哈希值；
    所述第一记账节点根据所述多个类型的同步子状态数据分别对应的叶哈希值进行哈希运算，得到根哈希值；
    所述第一记账节点根据所述根哈希值以及所述多个类型的同步子状态数据分别对应的叶哈希值，生成目标结构的状态数据。
  7. 根据权利要求1所述的区块链数据归档方法，其中，所述第一记账节点根据所述背书信息和所述归档点信息，对所述同步后区块链数据进行归档，包括：
    所述第一记账节点确定发送所述背书信息的第二记账节点的背书数量；
    当所述背书数量超过数量阈值时，所述第一记账节点将所述背书信息添加至所述归档点信息中，得到更新后归档点信息；
    所述第一记账节点将所述更新后归档点信息发送至所述共识节点；
    当所述第一记账节点接收到所述共识节点针对所述更新后归档点信息发送的配置区块数据时，所述第一记账节点对所述同步后区块链数据进行归档。
  8. 根据权利要求7所述的区块链数据归档方法，其中，所述同步后区块链数据包括第一区块数据；
    所述第一记账节点对所述同步后区块链数据进行归档，包括：
    所述第一记账节点对所述更新后归档点信息进行拷贝，以生成所述第一记账节点在所述同步区块高度的归档数据快照；
    所述第一记账节点将所述配置区块数据添加至所述第一区块数据中，得到更新后第一区块数据；
    所述第一记账节点在所述更新后第一区块数据中筛选出区块高度未超过所述同步区块高度的目标区块数据；
    所述第一记账节点将所述目标区块数据进行删除。
  9. 根据权利要求8所述的区块链数据归档方法，其中，当所述第一记账节点将所述目标区块数据进行删除时，还包括：
    所述第一记账节点将所述目标区块数据存储至分布式存储系统中；
    其中，所述分布式存储系统区别于所述区块链系统。
  10. 根据权利要求7所述的区块链数据归档方法，其中，所述第一记账节点将所述更新后归档点信息发送至所述共识节点之后，还包括：
    所述共识节点在所述更新后归档点信息中筛选出所述背书信息和所述签名信息；
    所述共识节点对所述背书信息和所述签名信息进行校验；
    当所述共识节点对所述背书信息和所述签名信息校验通过时，所述共识节点生成配置区块，并将所述更新后归档点信息存储至所述配置区块，得到配置区块数据；
    所述共识节点将所述配置区块数据发送至所述第一记账节点和所述第二记账节点。
  11. 根据权利要求10所述的区块链数据归档方法，其中，所述共识节点对所述背书信息和所述签名信息进行校验，包括：
    所述共识节点对所述背书信息的数量、以及所述背书信息对应的第二记账节点的身份标识中的至少之一进行校验；
    所述共识节点根据签名格式以及签名规则中的至少之一，对所述签名信息进行校验。
  12. 根据权利要求1至11任一项所述的区块链数据归档方法，其中，还包括：
    当所述第一记账节点接收到所述第二记账节点发送的所述归档点信息时，所述第一记账节点从所述归档点信息中提取出所述第二记账节点的状态数据的根哈希值；
    所述第一记账节点将所述第二记账节点的状态数据的根哈希值与所述第一记账节点自身状态数据的根哈希值进行对比；
    当所述第二记账节点的状态数据的根哈希值与所述第一记账节点自身状态数据的根哈希值相同时，所述第一记账节点对所述归档点信息进行签名，得到所述归档点信息的背书信息；
    所述第一记账节点将所述背书信息发送至所述第二记账节点，并将所述归档点信息在所述区块链系统中进行广播。
  13. 根据权利要求1至11任一项所述的区块链数据归档方法，其中，还包括：
    当所述第一记账节点为所述区块链系统中新增的记账节点时，所述第一记账节点向所述共识节点发送同步请求，并接收所述共识节点针对所述同步请求发送的背书信息和归档点信息；
    所述第一记账节点根据所述背书信息和所述归档点信息，从所述第二记账节点获取状态数据；
    所述第一记账节点从所述共识节点或所述第二记账节点获取区块高度超过所述同步区块高度的第二区块数据；
    所述第一记账节点根据所述第二区块数据中的交易信息，对所述状态数据进行更新，得到所述第一记账节点的当前区块链数据。
  14. 根据权利要求13所述的区块链数据归档方法，其中，所述归档点信息包括所述共识节点的状态数据的根哈希值和所述第二记账节点的签名信息；
    所述第一记账节点根据所述背书信息和所述归档点信息，从所述第二记账节点获取状态数据，包括：
    所述第一记账节点对所述背书信息和所述第二记账节点的签名信息进行校验；
    当所述第一记账节点对所述背书信息和所述第二记账节点的签名信息校验通过时，所述第一记账节点确定所述根哈希值对应的多个叶哈希值；
    所述第一记账节点从所述第二记账节点中并行获取不同所述叶哈希值对应的子状态数据，以作为得到的状态数据。
  15. 根据权利要求14所述的区块链数据归档方法，其中，所述第一记账节点从所述第二记账节点中并行获取不同所述叶哈希值对应的子状态数据，包括：
    所述第一记账节点根据所述第二记账节点的数量，对所述多个叶哈希值进行分类；
    所述第一记账节点根据对所述多个叶哈希值的分类结果，确定不同所述第二记账节点对应的目标叶哈希值；
    所述第一记账节点从不同所述第二记账节点获取所述目标叶哈希值对应的子状态数据。
  16. 根据权利要求1至11任一项所述的区块链数据归档方法，其中，所述第一记账节点与所述共识节点进行区块链数据同步，包括：
    所述第一记账节点向所述共识节点发送同步请求，所述同步请求包括所述第一记账节点的身份标识；
    所述第一记账节点接收所述共识节点针对所述同步请求发送的区块；其中，所述区块是所述共识节点对所述同步请求中的所述第一记账节点的身份标识校验通过时发送的；
    所述第一记账节点根据所述共识节点发送的区块，对本地的区块链数据进行更新，得到同步后区块链数据。
  17. 根据权利要求1至11任一项所述的区块链数据归档方法，其中，所述第一记账节点在所述状态数据中确定当前交易所需的目标状态数据，包括：
    所述第一记账节点将所述同步区块高度与归档区块高度进行匹配；
    当所述同步区块高度与所述归档区块高度匹配成功时，所述第一记账节点在所述状态数据中确定当前交易所需的目标状态数据。
  18. 一种区块链数据归档装置，用于区块链系统，所述区块链系统包括共识节点、第一记账节点和第二记账节点，所述装置包括：
    同步单元，配置为所述第一记账节点与所述共识节点进行区块链数据同步，并确定同步后区块链数据的同步区块高度，所述同步后区块链数据包括状态数据；
    确定单元，配置为所述第一记账节点在所述状态数据中确定当前交易所需的目标状态数据，并对所述目标状态数据进行备份；
    生成单元，配置为所述第一记账节点根据备份后的目标状态数据生成所述同步区块高度的状态数据快照，将所述状态数据快照、所述同步区块高度和所述第一记账节点的签名信息共同作为归档点信息，并发送至所述第二记账节点；
    接收单元，配置为所述第一记账节点接收所述第二记账节点针对所述归档点信息的背书信息；
    归档单元，配置为所述第一记账节点根据所述背书信息和所述归档点信息，对所述同步后区块链数据进行归档。
  19. 一种电子设备，包括：
    存储器，用于存储可执行指令；
    处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至17任一项所述的区块链数据归档方法。
  20. 一种计算机可读存储介质，所述计算机可读存储介质存储有可执行指令，用于被处理器执行时，实现权利要求1至17任一项所述的区块链数据归档方法。
PCT/CN2021/080371 2020-04-24 2021-03-12 一种区块链数据归档方法、装置和计算机可读存储介质 WO2021213065A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022539416A JP7330596B2 (ja) 2020-04-24 2021-03-12 ブロックチェーンデータのアーカイブ方法、ブロックチェーンデータのアーカイブ装置、電子機器、及びコンピュータプログラム
US17/703,085 US20220214995A1 (en) 2020-04-24 2022-03-24 Blockchain data archiving method, apparatus, and computer-readable storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010329695.3A CN111209346B (zh) 2020-04-24 2020-04-24 一种区块链数据归档方法、装置和计算机可读存储介质
CN202010329695.3 2020-04-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/703,085 Continuation US20220214995A1 (en) 2020-04-24 2022-03-24 Blockchain data archiving method, apparatus, and computer-readable storage medium

Publications (1)

Publication Number Publication Date
WO2021213065A1 true WO2021213065A1 (zh) 2021-10-28

Family

ID=70784399

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/080371 WO2021213065A1 (zh) 2020-04-24 2021-03-12 一种区块链数据归档方法、装置和计算机可读存储介质

Country Status (4)

Country Link
US (1) US20220214995A1 (zh)
JP (1) JP7330596B2 (zh)
CN (1) CN111209346B (zh)
WO (1) WO2021213065A1 (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111209346B (zh) 2020-04-24 2020-07-28 腾讯科技（深圳）有限公司 一种区块链数据归档方法、装置和计算机可读存储介质
CN112073484B (zh) * 2020-08-28 2022-01-04 武汉大学 一种基于联盟链的gdpr合规监管方法及系统
CN112073483B (zh) * 2020-08-28 2022-01-04 武汉大学 基于信誉与委员会背书机制的权威证明共识方法及系统
CN112184206A (zh) * 2020-09-30 2021-01-05 杭州复杂美科技有限公司 数据获取方法、设备和存储介质
KR102473672B1 (ko) * 2020-10-20 2022-12-02 주식회사 커먼컴퓨터 트리 구조의 상태 데이터베이스를 포함하는 블록체인에 대한 상태 관리 방법 및 시스템
CN112383610B (zh) * 2020-11-11 2022-12-09 上海保险交易所股份有限公司 区块链状态数据的同步处理方法及系统
CN112650733A (zh) * 2020-12-28 2021-04-13 杭州趣链科技有限公司 一种智能合约状态数据的处理方法、系统与装置
CN112291376B (zh) * 2020-12-31 2021-04-09 腾讯科技（深圳）有限公司 区块链系统中的数据处理方法及相关设备
CN112925479A (zh) * 2021-02-20 2021-06-08 京东数字科技控股股份有限公司 区块链数据管理方法及装置、电子设备及介质
CN113297214B (zh) * 2021-05-06 2022-06-10 湖南兆物信链科技集团有限公司 基于dag区块链的快照处理方法、设备及存储介质
CN113364847B (zh) * 2021-05-31 2022-07-19 新疆大学 区块链节点的数据同步方法、装置及存储介质
CN113610527A (zh) * 2021-08-24 2021-11-05 上海点融信息科技有限责任公司 联盟链的交易方法、装置、系统、终端设备及存储介质
US20230147295A1 (en) * 2021-11-05 2023-05-11 Salesforce.Com, Inc. Mechanisms for grouping nodes
CN114745131A (zh) * 2022-04-06 2022-07-12 广东钜联信息科技有限公司 一种区块链的pbft改进共识算法
CN114938380B (zh) * 2022-06-23 2023-08-22 成都质数斯达克科技有限公司 一种适用于区块链的数据共享系统及方法
CN117633099A (zh) * 2022-08-15 2024-03-01 财付通支付科技有限公司 一种基于区块链的数据处理方法、设备以及可读存储介质
CN115934849B (zh) * 2023-03-13 2023-05-30 安徽中科晶格技术有限公司 区块的工作量证明共识方法、装置、节点及存储介质
CN116663068B (zh) * 2023-07-31 2023-12-29 腾讯科技（深圳）有限公司 联盟链归档方法、相关装置和介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107526775A (zh) * 2017-07-18 2017-12-29 杭州趣链科技有限公司 一种区块链数据归档的方法
CN109656873A (zh) * 2018-11-02 2019-04-19 平安科技（深圳）有限公司 基于区块链的数据归档方法、装置及终端设备
CN110717764A (zh) * 2019-10-21 2020-01-21 深圳前海环融联易信息科技服务有限公司 多账本管理方法、装置、计算机设备及存储介质
US20200026712A1 (en) * 2017-04-12 2020-01-23 Vijay Madisetti Method and System for Tuning Blockchain Scalability, Decentralization, and Security for Fast and Low-Cost Payment and Transaction Processing
CN111209346A (zh) * 2020-04-24 2020-05-29 腾讯科技（深圳）有限公司 一种区块链数据归档方法、装置和计算机可读存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103150232B (zh) * 2013-02-01 2016-06-01 浪潮(北京)电子信息产业有限公司 存储快照创建方法和装置
CN107423426B (zh) 2017-08-02 2020-06-02 众安信息技术服务有限公司 一种区块链块数据的数据归档方法及电子设备
US11494344B2 (en) 2018-03-06 2022-11-08 International Business Machines Corporation Customized endorsement logic for blockchain
AU2019232978A1 (en) 2018-03-14 2020-08-13 Jieqian ZHENG Block chain data processing method, management terminal, user terminal, conversion device, and medium
CN109189853B (zh) * 2018-08-08 2021-05-28 众安信息技术服务有限公司 一种区块链之间数据同步方法与装置
CN109347941A (zh) * 2018-10-10 2019-02-15 南京简诺特智能科技有限公司 一种基于区块链的数据共享平台及其实现方法
CN110011788B (zh) * 2019-04-10 2020-12-25 深圳市网心科技有限公司 一种基于区块链的数据处理方法、系统及相关设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200026712A1 (en) * 2017-04-12 2020-01-23 Vijay Madisetti Method and System for Tuning Blockchain Scalability, Decentralization, and Security for Fast and Low-Cost Payment and Transaction Processing
CN107526775A (zh) * 2017-07-18 2017-12-29 杭州趣链科技有限公司 一种区块链数据归档的方法
CN109656873A (zh) * 2018-11-02 2019-04-19 平安科技（深圳）有限公司 基于区块链的数据归档方法、装置及终端设备
CN110717764A (zh) * 2019-10-21 2020-01-21 深圳前海环融联易信息科技服务有限公司 多账本管理方法、装置、计算机设备及存储介质
CN111209346A (zh) * 2020-04-24 2020-05-29 腾讯科技（深圳）有限公司 一种区块链数据归档方法、装置和计算机可读存储介质

Also Published As

Publication number Publication date
CN111209346B (zh) 2020-07-28
JP7330596B2 (ja) 2023-08-22
CN111209346A (zh) 2020-05-29
JP2023509006A (ja) 2023-03-06
US20220214995A1 (en) 2022-07-07

Similar Documents

Publication Publication Date Title
WO2021213065A1 (zh) 一种区块链数据归档方法、装置和计算机可读存储介质
US10904009B2 (en) Blockchain implementing delta storage
US11895223B2 (en) Cross-chain validation
US11257081B2 (en) Integrating a blockchain ledger with an application external to the blockchain ledger
US11212076B2 (en) Distributed platform for computation and trusted validation
US11200260B2 (en) Database asset fulfillment chaincode deployment
CN106991035A (zh) 一种基于微服务架构的主机监控系统
US11784789B2 (en) Distributed platform for computation and trusted validation
US11599431B2 (en) Database optimized disaster recovery orchestrator
JP2021525931A (ja) ブロックチェーンのための効率的な検証
US11593316B2 (en) Database snapshot for managing state synchronization
US11354198B2 (en) Snapshot for world state recovery
US11003523B2 (en) Database optimized disaster recovery testing
US11177938B2 (en) Database composite endorsement
US11940978B2 (en) Distributed platform for computation and trusted validation
CN108810112B (zh) 一种市场监管区块链系统的节点同步方法及装置
US11645268B2 (en) Database world state performance improvement
US20200021602A1 (en) Trace-based transaction validation and commitment
US11816069B2 (en) Data deduplication in blockchain platforms
US11050822B2 (en) Secure data dissemination
CN108092936A (zh) 一种基于插件架构的主机监控系统
US11144645B2 (en) Blockchain technique for immutable source control
US20200159928A1 (en) Blockchain technique for immutable source control
CN112035291A (zh) 快照恢复
US11321298B1 (en) Automated merge of DLT networks

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022539416

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED DD/MM/YYYY16/03/2023

122 Ep: pct application non-entry in european phase

Ref document number: 21793440

Country of ref document: EP

Kind code of ref document: A1