Blockchain network-based data processing method, device, equipment and medium

Abstract

Embodiments of the present application disclose a data processing method and device based on a blockchain network, equipment and a medium. The method comprises: a consensus node establishing a first connection channel and a second connection channel with a consensus backup node possessed by the consensus node, the first connection channel and the second connection channel corresponding to different data synchronization modes; synchronizing memory data written in a local memory of the consensus node to the consensus backup node through the first connection channel to back up the memory data; and synchronizing a transaction ledger stored in a local database of the consensus node to the consensus backup node through the second connection channel to back up the transaction ledger. The technical solution of the embodiments of the present application improves the disaster tolerance of consensus work while ensuring data security and integrity.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a data processing method based on a blockchain network, a data processing device based on a blockchain network, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In related technologies, blockchain networks include consensus networks, which are composed of various consensus nodes. These nodes can participate in the consensus process to realize the consensus mechanism of the blockchain network. However, when a consensus node in the consensus network fails, the data in that node will be lost to a certain extent, making the data insecure, and the node will no longer be able to participate in the consensus process. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a data processing method, a data processing device, an electronic device, a computer-readable storage medium, and a computer program product based on a blockchain network, which improves the disaster recovery capability of consensus operations while ensuring data security and integrity.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a data processing method based on a blockchain network is provided. The blockchain network includes consensus nodes, and each consensus node has a consensus backup node. The method includes: establishing a first connection channel and a second connection channel with the consensus backup node, wherein the first connection channel and the second connection channel correspond to different data synchronization methods; synchronizing memory data written in the local memory of the consensus node to the consensus backup node for backup of the memory data through the first connection channel; and synchronizing transaction ledger stored in the local database of the consensus node to the consensus backup node for backup of the transaction ledger through the second connection channel.

[0006] According to one aspect of the embodiments of this application, a data processing method based on a blockchain network is also provided. The blockchain network includes consensus nodes, and each consensus node has a consensus backup node. The method includes: establishing a first connection channel and a second connection channel with the consensus node, wherein the first connection channel and the second connection channel correspond to different data synchronization methods; receiving memory data written to the local memory of the consensus node synchronized by the consensus node through the first connection channel; receiving a transaction ledger stored in the local database of the consensus node synchronized by the consensus node through the second connection channel; and backing up the memory data and the transaction ledger.

[0007] According to one aspect of the embodiments of this application, a data processing device based on a blockchain network is provided. The blockchain network includes consensus nodes, and each consensus node has a consensus backup node. The device is deployed in the consensus node and includes: a first establishment module, configured to establish a first connection channel and a second connection channel with the consensus backup node, wherein the first connection channel and the second connection channel correspond to different data synchronization methods; a synchronization module, configured to synchronize memory data written in the local memory of the consensus node to the consensus backup node for backup of the memory data through the first connection channel; and the synchronization module, configured to synchronize transaction ledger stored in the local database of the consensus node to the consensus backup node for backup of the transaction ledger through the second connection channel.

[0008] In one embodiment of this application, the synchronization module is further configured to obtain the state data cached in the local cache of the consensus node and the transaction data written in the local transaction pool of the consensus node; put the state data and the transaction data into a message queue, and synchronize the state data and the transaction data to the consensus backup node through the message queue to back up the state data and the transaction data.

[0009] In one embodiment of this application, the synchronization module is further configured to verify whether the status data and transaction data corresponding to the block to be synchronized are complete; if the status data and transaction data are both complete, the status data and transaction data are placed into the message queue.

[0010] In one embodiment of this application, the synchronization module is further configured to obtain the queue sequence numbers corresponding to the status data and the transaction data respectively; and to put the status data and the transaction data into the message queue according to the queue sequence number, so that the consensus backup node can check whether the synchronized data is complete according to the queue sequence number.

[0011] In one embodiment of this application, the state data is backed up in the consensus backup node using a Merkle tree structure; the synchronization module is further configured to obtain the changed state data if the state data changes; put the changed data and the new Merkle root after the state data change into the message queue, so that the consensus backup node backs up the changed data and verifies the consistency of the backed-up state data according to the changed data and the new Merkle root.

[0012] In one embodiment of this application, the synchronization module is further configured to synchronize the transaction ledger stored in the local database to the consensus backup node for backup via a database master-slave synchronization method.

[0013] According to one aspect of the embodiments of this application, a data processing apparatus based on a blockchain network is provided. The blockchain network includes consensus nodes, and each consensus node has a consensus backup node. The apparatus is deployed in the consensus backup node and includes: a second establishment module, configured to establish a first connection channel and a second connection channel with the consensus node, wherein the first connection channel and the second connection channel correspond to different data synchronization methods; a receiving module, configured to receive memory data written to the local memory of the consensus node synchronized by the consensus node through the first connection channel; the receiving module is further configured to receive a transaction ledger stored in the local database of the consensus node synchronized by the consensus node through the second connection channel; and a backup module, configured to back up the memory data and the transaction ledger.

[0014] In one embodiment of this application, the memory data written to the local memory of the consensus node includes state data cached in the local cache and transaction data written to the local transaction pool; the receiving module is further configured to receive the state data and the transaction data through a message queue; the backup module is further configured to back up the state data to the local cache of the consensus backup node and back up the transaction data to the local transaction pool of the consensus backup node.

[0015] In one embodiment of this application, the apparatus further includes a verification module, which is configured to generate a Merkle tree of the state data in the local cache of the consensus backup node; receive change data of the state data and a new Merkle root after the change of the state data through the message queue; back up the change data to the local cache of the consensus backup node; calculate a target Merkle root based on the change data, and compare the target Merkle root with the new Merkle root to verify whether the state data in the local cache of the consensus backup node is consistent with the state data in the consensus node based on the comparison result.

[0016] In one embodiment of this application, the receiving module is further configured to receive the transaction ledger via a database master-slave synchronization method; the backup module is further configured to back up the transaction ledger to the local database of the consensus backup node.

[0017] In one embodiment of this application, the apparatus further includes a replacement module, which is used to receive a trigger instruction sent by a third-party node when the consensus node crashes; and to activate the consensus function according to the trigger instruction, so as to replace the consensus node in the consensus process according to the consensus function of the consensus backup node.

[0018] According to one aspect of the embodiments of this application, an electronic device is provided, including one or more processors; and a storage device for storing one or more computer programs, which, when executed by the one or more processors, cause the electronic device to implement the data processing method based on a blockchain network as described above.

[0019] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor of an electronic device, causes the electronic device to perform the data processing method based on a blockchain network as described above.

[0020] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the data processing method based on a blockchain network as described above.

[0021] In the technical solution provided in the embodiments of this application, the consensus node and the consensus backup node establish a first connection channel and a second connection channel with different data synchronization methods. Then, the memory data written in memory and the transaction ledger in the database are synchronized to the consensus backup node for backup through different data methods. This allows the consensus backup node to quickly back up relevant data and maintain consistency with the data of the consensus node. On the one hand, this ensures data security and integrity while improving the recoverability of the consensus node. On the other hand, when the consensus node encounters problems, the relevant data backed up by the consensus backup node can ensure the disaster recovery of the consensus operation.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0024] Figure 1 This is a schematic diagram of the blockchain network structure; Figure 2 This is a diagram illustrating the connection relationships between blocks in a blockchain. Figure 3 This is a schematic diagram illustrating the architecture of a blockchain network, as shown in an exemplary embodiment of this application; Figure 4 This is a schematic diagram illustrating an application scenario of a blockchain network in electronic invoices, as shown in an exemplary embodiment of this application; Figure 5 This is one implementation environment involved in this application; Figure 6 This is a flowchart illustrating a data processing method based on a blockchain network, as shown in an exemplary embodiment of this application. Figure 7 This is a flowchart illustrating another data processing method based on a blockchain network, as shown in an exemplary embodiment of this application; Figure 8 This is a flowchart illustrating another data processing method based on a blockchain network, as shown in an exemplary embodiment of this application; Figure 9 This is a flowchart illustrating another data processing method based on a blockchain network, as shown in an exemplary embodiment of this application; Figure 10 This is a flowchart illustrating another data processing method based on a blockchain network, as shown in an exemplary embodiment of this application; Figure 11 This is a flowchart illustrating another data processing method based on a blockchain network, as shown in an exemplary embodiment of this application; Figure 12 This is a flowchart illustrating a data processing method based on a blockchain network, as shown in another exemplary embodiment of this application; Figure 13 This is a flowchart illustrating another data processing method based on a blockchain network, as shown in an exemplary embodiment of this application; Figure 14 This is a flowchart illustrating another data processing method based on a blockchain network, as shown in an exemplary embodiment of this application; Figure 15 This is a flowchart illustrating another data processing method based on a blockchain network, as shown in an exemplary embodiment of this application; Figure 16 This is a flowchart illustrating a data processing method based on a blockchain network, as shown in another exemplary embodiment of this application; Figure 17 This is a schematic diagram illustrating the structure of a consensus node and a consensus backup node, as shown in another exemplary embodiment of this application. Figure 18 This is a schematic diagram illustrating the state data of a Merkle tree structure, as shown in another exemplary embodiment of this application; Figure 19 This is a flowchart illustrating another exemplary embodiment of the present application, showing another data processing method based on a blockchain network; Figure 20 This is a structural block diagram of a data processing apparatus based on a blockchain network, as illustrated in an exemplary embodiment of this application. Figure 21 This is a structural block diagram of a data processing apparatus based on a blockchain network, as illustrated in an exemplary embodiment of this application. Figure 22 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0026] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0027] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0028] It should also be noted that "multiple" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0029] The technical solutions of the embodiments of this application relate to the field of blockchain technology. Before introducing the technical solutions of the embodiments of this application, blockchain technology will be briefly introduced first.

[0030] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks (i.e., blocks) linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0031] As mentioned above, a blockchain is essentially a decentralized database, and it is maintained collaboratively by nodes within a blockchain network. For example, please refer to... Figure 1 ,exist Figure 1 The blockchain network shown may include multiple nodes 101, which can be various servers or terminals forming the blockchain network. Each node 101, in its normal operation, receives input information and maintains shared data within the blockchain network based on this information. To ensure information exchange within the blockchain network, information connections can exist between each node, allowing for information transmission. For example, when any node in the blockchain network receives input information, other nodes in the network obtain this input information according to a consensus algorithm and store it as shared data, ensuring consistency of data stored on all nodes in the blockchain network.

[0032] Each node in a blockchain network has a corresponding node identifier, and each node can store the node identifiers of other nodes. This allows for the broadcast of generated blocks to other nodes in the blockchain network based on their node identifiers. Each node can maintain a list of node identifiers, storing the node name and its corresponding node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0033] Nodes form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol that runs on top of the Transmission Control Protocol (TCP). In a distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0034] Please see Figure 2A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information features, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block is the parent block of the genesis block. The next block also includes a block header and a block body. The block header stores the input information features of the current block, the block header features of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0035] The core of blockchain is its consensus mechanism. The consensus process generally consists of three stages: block creation, block verification, and block submission. According to the consensus protocol, a master node is selected from the participating nodes to create a new block (defined as the node that produces a valid block in each round of consensus). The new block is then independently verified by the other participating nodes. Once verified, the new block is submitted to the local blockchain by the node, achieving consensus on the latest block height. This completes the consensus process and initiates the next round.

[0036] It is understood that nodes in a blockchain network can be servers or terminals. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and intelligent platforms. Terminals can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, terminals used in vehicles, aircraft, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0037] Based on blockchain technology, the architecture of the blockchain network proposed in the embodiments of this application is described in detail: Please see Figure 3 , Figure 3The illustrated blockchain network includes a witness network 310 and a consensus network 320, both of which can be P2P networks. Nodes in the witness network are business nodes 311. Business nodes 311 do not participate in consensus but obtain partial data from the consensus network 320 through identity authentication. This partial data can be block header data or partially authorized visible block data. Nodes in the consensus network 320 are consensus nodes 321. Consensus nodes 321 run the blockchain consensus protocol, reach consensus on block data, and record the consensus-passed blocks on the blockchain.

[0038] It should be noted that the witness network 310 and the consensus network 320 are located in different network environments. The witness network 310 is in a public network, while the consensus network 320 is in a private network. The business node 311 in the witness network 310 and the consensus node 321 in the consensus network 320 interact through a routing boundary. For example, they can interact through a proxy node at the edge of the witness network. The business node 311 can generate transaction data to be uploaded to the chain, which can be transmitted to the consensus node 321 through the proxy node for consensus. The business node 311 can also query transaction data and receive the queried transaction data sent by the consensus node 321 forwarded by the proxy node.

[0039] Since the consensus network resides in a relatively secure private cloud, its mutual access is inherently secured by a consensus mechanism, eliminating the need for additional identity management and network control. In contrast, business nodes are located in public networks and may be accessed by other unidentified network terminals. Therefore, the access of business nodes and other potential nodes to the consensus network requires strict control.

[0040] Figure 3 The blockchain network in this context can be applied to electronic invoice scenarios. In this case, business nodes can be local invoicing terminals, enterprise invoicing terminals, individual terminals, etc.; consensus nodes can be various official invoicing terminals. For example... Figure 4 As shown, the entire blockchain network can include a business layer, a routing agent layer, and a consensus network layer. The business layer is the business network, which includes various business nodes, such as local invoicing terminals in the invoicing private network; invoicing service providers, reimbursement service providers, and enterprises in the public cloud; and payment service providers, circulation service providers, and enterprises in the private cloud.

[0041] The routing proxy layer includes proxy nodes, which can implement functions such as routing services, certificate caching, authentication services, and P2P services. The routing proxy layer plays a role in isolating the business layer and the consensus network layer.

[0042] The consensus network layer consists of multiple blockchains, and each blockchain includes multiple consensus nodes in the invoicing network.

[0043] In one embodiment of this application, in order to improve the disaster recovery capability of consensus operations while ensuring data security and integrity, this embodiment extracts a data processing method based on a blockchain network. Please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic diagram of an implementation environment involved in this application. The implementation environment includes a consensus network, which includes consensus nodes. Each consensus node has a consensus backup node, and the backup node is only connected to the consensus node. It is possible that every consensus node has a consensus backup node; or it is possible that some consensus nodes have consensus backup nodes, which is not limited here.

[0044] The consensus node establishes a first connection channel and a second connection channel with the consensus backup node. The first connection channel and the second connection channel correspond to different data synchronization methods. The memory data written in the local memory of the consensus node is synchronized to the consensus backup node through the first connection channel. The transaction ledger stored in the local database of the consensus node is synchronized to the consensus backup node through the second connection channel.

[0045] Consensus backup nodes can receive memory data and transaction ledgers from consensus nodes through the first and second connection channels, respectively, and then back up the memory data and transaction ledgers, so that rapid fault recovery can be performed when consensus nodes fail.

[0046] It should be noted that, in the specific implementation of this application, if the memory data and / or transaction ledger involve objects, then when the embodiments of this application are applied to specific products or technologies, permission or consent from the objects is required, and the collection, use and processing of related data must comply with the relevant regulations and standards of the relevant countries and regions.

[0047] The following details the various implementation details of the technical solutions in the embodiments of this application: like Figure 6 As shown, Figure 6 This is a flowchart illustrating a data processing method based on a blockchain network, as shown in one embodiment of this application. This method can be applied to... Figure 5 The implementation environment shown indicates that this method can be implemented by Figure 5 The consensus node shown in the diagram executes the data processing method based on the blockchain network, which may include steps S610 to S630, as detailed below: S610: Establish a first connection channel and a second connection channel with the consensus backup node. The first connection channel and the second connection channel correspond to different data synchronization methods.

[0048] In this embodiment of the application, the consensus node and the consensus backup node establish a first connection channel and a second connection channel. The connection channel refers to the channel that connects the consensus node and the consensus backup node. Through the connection channel, the consensus node and the consensus backup node can interact with each other.

[0049] The first connection channel and the second connection channel are different, and the first connection channel and the second connection channel correspond to different data synchronization methods. The data synchronization method refers to the way to synchronize the data of the consensus node to the consensus backup node.

[0050] S620: Synchronize the memory data written in the local memory of the consensus node to the consensus backup node through the first connection channel to back up the memory data.

[0051] The local memory of a consensus node refers to the workplace of the consensus node. All programs in the consensus node run in memory. Memory is used to temporarily store data generated during program execution, as well as data exchanged with external storage devices such as hard drives. For example, the memory data written to memory can be data generated by the consensus node running consensus programs, or data generated by executing smart contracts.

[0052] In this embodiment, the first connection channel is used to synchronize the memory data written to the local memory of the consensus node. The consensus node transmits the memory data written to its local memory to the first connection channel, and then synchronizes the memory data to the consensus backup node through the first connection channel, so that the consensus backup node can back up the memory data. Here, the consensus backup node backing up the memory data means that the consensus backup node stores the memory data.

[0053] S630. The transaction ledger stored in the local database of the consensus node is synchronized to the consensus backup node through the second connection channel to back up the transaction ledger.

[0054] The consensus node's local database is stored on disk. That is, the transaction ledger stored in the database is ultimately located on disk. The transaction ledger includes the blockchain structure (with all transaction information) and the current world state. The world state is the latest global ledger state, which is used to store the latest state generated after historical transactions. It can be implemented using a key-value or document database.

[0055] In this embodiment of the application, the second connection channel is used to synchronize the transaction ledger stored in the local database of the consensus node. The consensus node transmits the transaction ledger stored in the local database to the second connection channel, and then the second connection channel synchronizes the transaction ledger to the consensus backup node so that the consensus backup node can back up the transaction ledger.

[0056] It should be noted that the execution of steps S620 and S630 is not sequential. That is, the memory data can be synchronized through the first connection channel first, the transaction ledger can be synchronized through the second connection channel first, or they can be performed simultaneously, that is, the transaction ledger can be synchronized through the second connection channel while the memory data is synchronized through the first connection channel.

[0057] In this embodiment, the consensus node and the consensus backup node establish a first connection channel and a second connection channel with different data synchronization methods. Then, the memory data written in memory and the transaction ledger in the database are synchronized to the consensus backup node for backup through different data methods. This allows the consensus backup node to quickly back up relevant data and maintain consistency with the data of the consensus node. In this way, while ensuring data security and integrity, the recoverability of the consensus node is improved. Moreover, when the consensus node encounters problems, the disaster recovery capability of the consensus operation can be improved by using the relevant data backed up by the consensus backup node.

[0058] In one embodiment of this application, another data processing method based on a blockchain network is provided, which can be applied to... Figure 5 In the implementation environment shown, this method can be executed by a consensus node, such as... Figure 7 As shown, this data processing method based on blockchain networks... Figure 6 Based on what is shown, Figure 6 The step S620 shown is extended to steps S710~S720.

[0059] Steps S710 to S720 are described in detail below: S710: Obtain the state data cached in the local cache of the consensus node and the transaction data written in the local transaction pool of the consensus node.

[0060] In this embodiment, the memory data written to the consensus node's local memory includes state data cached in the local cache and transaction data written to the local transaction pool. The local cache can be a high-speed cache memory. State data refers to the information necessary for the consensus node to operate, corresponding to changes in transaction data. The state is modeled as a version key / value store (KVS), where the key name and value can be arbitrary. The entire process is operated by chaincode running on the blockchain, implemented through KVS storage and retrieval operations. In one example, state data includes, but is not limited to, request sessions sent to the consensus node, or request sessions issued by the consensus node, the state of a requested query, the query cache of smart contracts, system state data, etc.

[0061] Understandably, each consensus node has a transaction pool. Transaction data, whether created by the node itself or broadcast by other consensus nodes, is cached in the transaction pool. This transaction data refers to the data corresponding to executing a function call on the ledger or deploying and updating chaincode. Therefore, state data and transaction data can be extracted from the local cache and the local transaction pool.

[0062] In the example of Embodiment 1 of this application, the state data cached in the local cache and the transaction data written in the local transaction pool can be obtained simultaneously; or the data with a smaller amount of data can be obtained first, for example, if the amount of state data is less than the amount of transaction data, then the state data can be obtained first; or the state data and transaction data can be obtained periodically, such as obtaining the state data every 3 minutes and obtaining the transaction data every 5 minutes; or the data can be obtained in real time, as long as there is new data in the local cache or the local transaction pool, the new data can be obtained immediately, without any limitation.

[0063] S720: Place state data and transaction data into a message queue, and use the message queue to synchronize the state data and transaction data to the consensus backup node for backup.

[0064] In this embodiment of the application, a message queue can be created in the consensus node to connect to the consensus backup node. After the consensus node obtains the state data and transaction data, it puts the state data and transaction data into the message queue and then synchronizes the state data and transaction data to the consensus backup node for backup through the message queue.

[0065] In the example of Embodiment 1 of this application, when putting status data and transaction data into the message queue, one type of data can be put in first, and then another type of data can be put in. For example, all the status data can be put in first, and then all the transaction data can be put in. Alternatively, they can be put in alternately. For example, some status data can be put in first, then some transaction data can be put in, and then the remaining status data and transaction data can be put in.

[0066] In another example of the embodiments of this application, the status data and transaction data can also be placed into the message queue according to the order of acquisition time, or the status data and transaction data can be placed at preset time intervals.

[0067] It should be noted that, Figure 7 For further details on steps S610 and S630 shown, please refer to [link / reference]. Figure 6 Steps S610 and S630 shown will not be repeated here.

[0068] This application embodiment obtains state data from the cache and transaction data from the transaction pool, and then puts the state data and transaction data into a message queue for synchronization, which can quickly realize the synchronization of memory data at the memory level.

[0069] This application provides another data processing method based on a blockchain network, which can be applied to... Figure 5 The implementation environment shown indicates that this method can be implemented by Figure 5 The consensus nodes shown in the figure are used to execute, such as Figure 8 As shown, this data processing method based on a blockchain network will... Figure 7 The S720 is extended to S810~S820. The steps S810~S820 are described in detail below: S810. Verify whether the status data and transaction data corresponding to the block to be synchronized are complete.

[0070] In this embodiment of the application, when the consensus node performs data synchronization, it does not require real-time data synchronization, but it does require data integrity, that is, the state data and transaction data corresponding to each block to be synchronized must be complete; therefore, before putting the state data and transaction data into the message queue, it is necessary to verify whether the state data and transaction data corresponding to the block to be synchronized are complete.

[0071] In the example of Embodiment 1 of this application, when obtaining state data and transaction data, the data can be obtained according to the data in each block to be synchronized. For example, if the data corresponding to block 1 to be synchronized includes state data 1 and transaction data 1, then state data 1 is extracted from the local cache and transaction data 1 is extracted from the local transaction pool, thus ensuring the integrity of the data.

[0072] In the example of Embodiment 1 of this application, after obtaining the status data and transaction data, the obtained data can be compared one by one with the data in the block to be synchronized to verify whether the data is complete.

[0073] S820. If both the state data and transaction data are complete, then the state data and transaction data are placed in the message queue, and the message queue is used to synchronize the state data and transaction data to the consensus backup node for backup.

[0074] In this embodiment, if both the state data and transaction data are complete, the consensus node places them into a message queue. If at least one of the state data or transaction data is incomplete, the state data and transaction data are retrieved again.

[0075] It should be noted that, Figure 8 For a detailed description of steps S610, S710, and S630 shown, please refer to [link to relevant documentation]. Figure 7 Steps S610, S710, and S630 shown will not be repeated here.

[0076] This application embodiment verifies the completeness of the state data and transaction data corresponding to the block to be synchronized to ensure data integrity. This allows the consensus backup node to start quickly when a consensus node fails, based on the characteristics of multi-node consensus in blockchain. If a small number of blocks are lagging behind, the consensus node's lagging synchronization mechanism can be used to synchronize with other consensus nodes.

[0077] This application also provides another data processing method based on a blockchain network, which can be applied to... Figure 5 The implementation environment shown indicates that this method can be implemented by Figure 5 The consensus nodes shown in the figure are used to execute, such as Figure 9 As shown, this data processing method based on blockchain networks... Figure 8 The S820 shown is extended to S910~S920, which not only needs to ensure data integrity before data synchronization, but also needs to ensure data integrity during transmission.

[0078] Steps S910 to S920 are described in detail below: S910. If both the status data and transaction data are complete, obtain the queue sequence numbers corresponding to the status data and transaction data respectively.

[0079] In this embodiment of the application, after obtaining the status data and transaction data, a queue sequence number can be assigned to the status data and transaction data. The queue sequence number is unique and is used to determine the amount of data synchronized by the consensus node.

[0080] In the example of Embodiment 1 of this application, queue sequence numbers can be assigned sequentially according to the order in which the data is acquired. For example, for status data, if status data 1 is acquired first, then queue sequence number 1 is assigned to status data 1; then if status data 2 is acquired, then queue sequence number 2 is assigned to status data 2; and so on until queue sequence number n is assigned to status data n. For transaction data, if transaction data 1 is acquired first, then queue sequence number n+1 is assigned to transaction data 1, and so on. For example, if status data 1 is acquired first, then queue sequence number 1 is assigned to status data 1; then if transaction data 1 is acquired, then queue sequence number 2 is assigned to transaction data 1. That is, regardless of which type of data is acquired first, the queue sequence numbers corresponding to status data and transaction data should be consecutive and unique.

[0081] In another example of the embodiments of this application, queue sequence numbers can also be randomly assigned to status data and transaction data, but the queue sequence numbers are unique; or queue sequence numbers can be assigned to status data and transaction data according to the order in which they are put into the message queue.

[0082] S920. Place the state data and transaction data into the message queue according to the queue sequence number, so that the consensus backup node can check whether the synchronized data is complete according to the queue sequence number.

[0083] After obtaining the queue sequence numbers corresponding to the status data and transaction data respectively, the status data and transaction data can be put into the message queue according to the queue sequence number. That is, the message queue includes each piece of data, and each piece of data carries a queue sequence number. Then, the consensus backup node verifies whether the synchronized data is complete according to the queue sequence number. For example, the consensus backup node checks whether there are any missing queue sequence numbers, and then verifies whether the synchronized data is complete.

[0084] In one embodiment of this application, the status data and transaction data are placed into the message queue according to the queue sequence number. This can be achieved by placing the data corresponding to the queue sequence number into the message queue in order of the queue sequence number size.

[0085] It should be noted that, Figure 9 For further details on steps S610, S710, S810, and S630 shown, please refer to [link / reference]. Figure 8 Steps S610, S710, S810, and S630 shown in the diagram will not be repeated here.

[0086] In this embodiment of the application, by obtaining the queue sequence number of the status data and transaction data, and then putting the status data and transaction data into the message queue according to the queue sequence number, the integrity of the data can be guaranteed when the data is put into the queue. It can also enable the consensus backup node to verify whether the synchronized data is complete based on the queue sequence number, thereby ensuring that the data backed up by the consensus backup node is consistent with the data of the consensus node.

[0087] In one embodiment of this application, another data processing method based on a blockchain network is also provided, which can be applied to... Figure 5 The implementation environment shown indicates that this method can be implemented by Figure 5 The consensus nodes shown in the figure are used to execute, such as Figure 10 As shown, this data processing method based on blockchain networks... Figure 7 Steps S1010 to S1020 are added after S720 shown.

[0088] In this process, the state data is backed up in the consensus backup node using a Merkle tree structure. The Merkle tree is a typical binary tree structure consisting of a root node, a set of intermediate nodes, and a set of leaf nodes. The bottom leaf nodes contain the state data or its hash value, while the non-leaf nodes (including the root node and intermediate nodes) contain the hash values ​​of the contents of their two child nodes. Any changes to the underlying data are propagated to its parent node, layer by layer along the path all the way to the root. Therefore, the Merkle tree can be used to verify whether the entire state data in the consensus node is consistent with the entire state data synchronized by the consensus backup node.

[0089] Steps S1010 to S1020 are described in detail below: S1010. If the state data changes, obtain the change data of the state data.

[0090] It is understandable that as time changes and the blockchain continues to operate, the state data cached in the local cache will change; as business increases, the state data will also change. Therefore, the current state data can be compared with the state data at the previous moment to determine whether the state data has changed. If the state data has changed, the change data of the state data is obtained, that is, the difference between the current state data and the state data at the previous moment is used as the change data of the state data.

[0091] S1020. Place the changed data and the new Merkle root after the state data changes into the message queue so that the consensus backup node can back up the changed data and verify the consistency of the backed-up state data based on the changed data and the new Merkle root.

[0092] It should be noted that the state data is also stored in a Merkle tree structure at the consensus nodes. Therefore, when the state data at a leaf node changes, it will be passed up to the corresponding parent node level by level, eventually causing the root hash value of the Merkle tree to change. Thus, a new Merkle root after the state data change can be obtained. The consensus node puts the new Merkle root and the changed data into the message queue. Then, the consensus backup node will back up the changed data, that is, update the corresponding state data, and verify the consistency of the backed-up state data based on the changed data and the new Merkle root.

[0093] In this embodiment of the application, when the root hash values ​​of two Merkle trees are the same, it means that the data they represent are the same, and the consistency of the backed-up state data can be verified through the new Merkle root.

[0094] It should be noted that, Figure 10 For further details on steps S610, S710~S720, and S630 shown, please refer to [link / reference]. Figure 7Steps S610, S710~S720, and S630 shown will not be repeated here.

[0095] In this application embodiment, the state data is stored using a Merkle tree structure, which can quickly summarize and verify the integrity of large-scale data. When the state data changes, the changed data and the new Merkle root after the state data change are put into the message queue, so that the consensus backup node can quickly compare whether the backed-up state data is consistent with the state data in the consensus node while backing up the changed data.

[0096] This application provides another data processing method based on a blockchain network, which includes methods applicable to... Figure 5 The implementation environment shown indicates that this method can be implemented by Figure 5 The consensus nodes shown in the figure are used to execute, such as Figure 11 As shown, this data processing method based on blockchain networks... Figure 6 The S630 shown is extended to step S1110.

[0097] Step S1110 is described in detail below: S1110. The transaction ledger stored in the local database is synchronized to the consensus backup node for backup via database master-slave synchronization.

[0098] In this embodiment, the consensus node synchronizes the transaction ledger stored in its local database to the consensus backup node via a database master-slave synchronization method. This database master-slave synchronization method can be based on a binary logging mechanism. The consensus node uses a binary log to record database changes, and the consensus backup node reads and runs this log file to maintain data integrity with the consensus node. Alternatively, the database master-slave synchronization method can be based on a database synchronization program (such as SyncNavigator).

[0099] In one example of this application, the data format in the database can be converted before master-slave synchronization. For example, master-slave synchronization between consensus nodes and consensus backup nodes can be based on LevelDB (a key-value database) format data to ensure that the backup node synchronizes the data to the master node in real time.

[0100] It is worth noting that when synchronizing the transaction ledger stored in the local database, it is also necessary to ensure data integrity. Therefore, it is also necessary to verify whether the transaction ledger corresponding to the block to be synchronized is complete. If the transaction ledger is complete, the transaction ledger is synchronized to the consensus backup node through the database master-slave synchronization method.

[0101] It should be noted that, Figure 11 For further details on steps S610-S620 shown, please refer to [link / reference]. Figure 6 Steps S610 to S620 shown in the diagram will not be repeated here.

[0102] This application embodiment synchronizes data from the database of the consensus node to the consensus backup node through a database master-slave synchronization method, ensuring that the consensus backup node synchronizes data to the consensus node in real time and quickly.

[0103] Figures 6 to 11 The illustrated embodiment is presented from the perspective of the consensus node. The following is combined with... Figures 12 to 16 The implementation details of the technical solution in this application embodiment are described in detail from the perspective of consensus backup nodes: Please see Figure 12 , Figure 12 This is a flowchart illustrating a data processing method based on a blockchain network, as shown in one embodiment of this application. This method can be... Figure 5 The consensus backup node shown is used to execute it. Figure 12 As shown, the data processing method based on the blockchain network may include steps S1210 to S1240, which are described in detail below: S1210. Establish a first connection channel and a second connection channel with the consensus node. The first connection channel and the second connection channel correspond to different data synchronization methods.

[0104] In this embodiment, the consensus backup node connects only to the consensus node via a first connection channel and a second connection channel. For a description of the first and second connection channels, please refer to [link to relevant documentation]. Figure 6 This will not be elaborated upon here.

[0105] S1220: Receive memory data written to the local memory of the consensus node through the first connection channel.

[0106] The consensus backup node receives the memory data synchronized by the consensus node through the first connection channel.

[0107] S1230: Receive the transaction ledger stored in the local database of the consensus node synchronized by the consensus node through the second connection channel.

[0108] The consensus backup node receives the transaction ledger synchronized by the consensus node through the second connection channel.

[0109] S1240, Back up memory data and transaction ledger.

[0110] In the embodiments of this application, the consensus backup node receives memory data and transaction data and performs backup. This backup can be performed immediately upon receiving the memory data or transaction ledger, or it can be performed uniformly after receiving all the data. No limitation is imposed here.

[0111] This application embodiment synchronizes the memory data written in memory and the transaction ledger in the database to the consensus backup node for backup through different data methods. This allows the consensus backup node to quickly back up relevant data and maintain consistency with the data of the consensus node. On the one hand, it ensures data security and integrity while improving the recoverability of the consensus node. On the other hand, when the consensus node encounters problems, the disaster recovery capability of the consensus operation can be improved by using the relevant data backed up by the consensus backup node.

[0112] This application provides another data processing method based on a blockchain network, which can be applied to... Figure 5 The implementation environment shown indicates that this method can be implemented by Figure 5 The consensus backup node shown is used to execute, such as Figure 13 As shown, this data processing method based on a blockchain network will... Figure 12 S1220 is extended to S1310, and S1240 is extended to S1320~S1330. The memory data written to the local memory of the consensus node includes the state data cached in the local cache and the transaction data written to the local transaction pool.

[0113] Steps S1310 to S1330 are described in detail below: S1310, Receive status data and transaction data through message queue.

[0114] In this embodiment of the application, a message queue connected to the consensus node can be created in the consensus backup node, and this message queue is connected to the message queue in the consensus node.

[0115] As mentioned earlier, the consensus node puts the state data and transaction data into the local message queue of the consensus node, and synchronizes the state data and transaction data to the consensus backup node through the local message queue of the consensus node. Then, the consensus backup node receives the state data and transaction data in the local message queue of the consensus backup node.

[0116] The status data and transaction data also carry queue sequence numbers. When the consensus backup node receives the status data and transaction data through the message queue, it can sort the data according to the queue sequence numbers. The consensus backup node can then verify whether any intermediate data is missing based on the queue sequence numbers. In some embodiments, the consensus node also puts the total number of queue sequence numbers into the message queue, allowing the consensus backup node to verify whether any data is missing based on the total queue sequence numbers.

[0117] S1320: Back up the state data to the local cache of the consensus backup node, and back up the transaction data to the local transaction pool of the consensus backup node.

[0118] It should be noted that the consensus node and the consensus backup node in this application embodiment have the same structure. That is, the consensus node has a cache and a transaction pool, and the consensus backup node also has a cache and a transaction pool. After receiving the state data and transaction data, the consensus backup node can back up the state data to the local cache of the consensus backup node and back up the transaction data to the local transaction pool of the consensus backup node.

[0119] S1330, Backup the transaction ledger.

[0120] After receiving the transaction ledger, the consensus backup node will back up the transaction ledger.

[0121] It should be noted that, Figure 13 For a detailed description of steps S1210 and S1230 shown, please refer to [link / reference]. Figure 12 Steps S1210 and S1230 shown in the diagram will not be repeated here.

[0122] In this embodiment, the status data in the buffer and the transaction data in the transaction pool are received through the message queue. While quickly synchronizing the memory data at the memory level, the integrity of the synchronized data can be verified based on the queue sequence number, thereby ensuring that the data backed up by the consensus backup node is consistent with the data of the consensus node.

[0123] It is worth noting that this application embodiment provides another data processing method based on a blockchain network, which can be applied to... Figure 5 The implementation environment shown indicates that this method can be implemented by Figure 5 The consensus backup node shown is used to execute, such as Figure 14 As shown, this data processing method based on blockchain networks... Figure 13 Following step S1320, steps S1410 to S1440 are added. The details of steps S1410 to S1440 are as follows: S1410. Generate a Merkle tree of state data in the local cache of the consensus backup node.

[0124] In this embodiment, after receiving the state data, the consensus backup node generates a Merkle tree in its local cache, meaning the state data is stored in a Merkle tree structure. The process of generating the Merkle tree for the state data includes: performing a hash calculation on each state data to obtain its corresponding hash value (i.e., a leaf node); then performing a hash calculation on two adjacent hash values ​​to obtain a parent node; then performing a hash calculation on adjacent parent nodes, and so on, until the Merkle root is obtained. Finally, the Merkle tree for the state data is generated using the leaf nodes, parent nodes, and the Merkle root.

[0125] S1420, Receive the status data change data and the new Merkle root after the status data change through the message queue.

[0126] As mentioned earlier, the consensus node will put the changed state data and the new Merkle root after the state data changes into the message queue, and the consensus backup node will receive the changed data and the new Merkle root in the message queue.

[0127] S1430: Back up the changed data to the local cache of the consensus backup node.

[0128] In this embodiment of the application, the consensus backup node stores the changed data backup value in the local cache to update the corresponding state data.

[0129] In one example of an embodiment of this application, when the consensus node puts the changed state data and the new Merkle root into the message queue, it also sends a Merkle root path connecting the changed state data and the new Merkle root. The consensus backup node then receives the Merkle root path through the message queue, looks up the corresponding state data using the Merkle path, and updates the found state data based on the changed data.

[0130] S1440. Calculate the target Merkle root based on the changed data, and compare the target Merkle root with the new Merkle root to verify whether the state data in the local cache of the consensus backup node is consistent with the state data in the consensus node based on the comparison result.

[0131] In a Merkle tree, changes in leaf node data propagate upwards to the corresponding parent node, eventually changing the hash value of the root node. Therefore, the consensus backup node can calculate the target Merkle root based on the changed data. The Merkle tree can quickly compare the consistency of large amounts of data by comparing the target Merkle root with the new Merkle root. If the target Merkle root and the new Merkle root are the same, it means that the data they represent are the same, that is, the state data in the local cache of the consensus backup node is completely consistent with the state data in the consensus node.

[0132] If the target Merkle root is different from the new Merkle root, it means that the state data in the local cache of the consensus backup node is inconsistent with the state data in the consensus node. At this time, the consensus node can resynchronize the state data, and the consensus backup node will delete the state data in its local cache and re-backup the synchronized state data.

[0133] In one example, when the state data in the local cache of the consensus backup node is inconsistent with the state data in the consensus node, the hash values ​​corresponding to each parent node, intermediate node, and leaf node can be reversed based on the target Merkle root and the new Merkle root to find out the inconsistent state data and resynchronize the inconsistent state data.

[0134] It should be noted that, Figure 14 For a detailed description of steps S1210, S1310, S1230, and S1320~S1330 shown in the diagram, please refer to [link to relevant documentation]. Figure 13 Steps S1210, S1310, S1230, and S1320~S1330 shown in the diagram will not be repeated here.

[0135] In this embodiment, the state data is stored using a Merkle tree structure, which can quickly summarize and verify the integrity of large-scale data. When the state data changes, the changed data and the new Merkle root after the change are put into the message queue, so that the consensus backup node can quickly compare whether the backed-up state data is consistent with the state data in the consensus node while backing up the changed data.

[0136] It is worth noting that this application embodiment provides another data processing method based on a blockchain network, which can be applied to... Figure 5 In the implementation environment shown, this method can be executed by a consensus backup node, such as... Figure 15 As shown, this data processing method based on blockchain networks... Figure 12 Based on this, Figure 12 S1230 is extended to S1510, and S1240 is extended to S1520~S1530. Steps S1510~S1530 are described in detail below: S1510. Receive transaction ledgers through database master-slave synchronization.

[0137] In this embodiment of the application, the consensus backup node has the same structure as the consensus node, and the databases of the consensus node and the consensus backup node are interconnected. Thus, the consensus node can synchronize the transaction ledger to the consensus backup node through the database master-slave synchronization method, and the consensus backup node receives the transaction ledger through the database master-slave synchronization method.

[0138] S1520: Back up the transaction ledger to the local database of the consensus backup node.

[0139] After receiving the transaction ledger, the consensus backup node can back up the transaction ledger to its local database to ensure that the consensus backup node is completely consistent with the consensus node.

[0140] S1530, Back up memory data.

[0141] It should be noted that, Figure 15 For a detailed description of steps S1210 and S1220 shown, please refer to [link / reference]. Figure 12 Steps S1210 and S1220 shown in the diagram will not be repeated here.

[0142] This application embodiment receives data from the database synchronized by the consensus node through a database master-slave synchronization method, ensuring that the consensus backup node synchronizes the data to the consensus node in real time and quickly, and the consensus backup node backs up the transaction ledger to the local database, so that the consensus backup node is consistent with the consensus node.

[0143] It is worth noting that this application embodiment provides another data processing method based on a blockchain network, which can be applied to... Figure 5 In the implementation environment shown, this method can be executed by a consensus backup node, such as... Figure 16 As shown, this data processing method based on blockchain networks... Figure 12 Steps S1610-S1620 are added after step S1240. Steps S1610-S1620 are the consensus replacement process for the consensus backup node, detailed below: S1610 Receive trigger instructions sent by third-party nodes. The trigger instructions are sent when the consensus node crashes.

[0144] In this embodiment, the third-party node can be another consensus node or a business node. The third-party node can access the consensus node, such as other consensus nodes transmitting blocks to be consensused to the consensus node; or business nodes transmitting generated transaction data to the consensus node. If the third-party node discovers that the consensus node is down when accessing it, it will generate a trigger command and send the trigger command to the consensus backup node.

[0145] It should be noted that when the consensus node is running normally, the consensus backup node only connects to the consensus node. However, in some examples, when the consensus node fails, the consensus backup node can automatically connect to other nodes. In another example, before the consensus node fails, it can notify the consensus backup node to connect to other nodes; for example, if the consensus node predicts that a failure will occur, it can notify the consensus backup node to connect to other nodes.

[0146] In other embodiments of this application, since the consensus backup node is only connected to the consensus node, the consensus backup node can determine whether the consensus node has crashed. If the consensus backup node determines that the consensus node has crashed, it can automatically generate a trigger command.

[0147] S1620. Start the consensus function according to the trigger instruction, and replace the consensus node with the consensus function of the consensus backup node to participate in the consensus process.

[0148] In this embodiment, the trigger instruction is used to trigger the consensus backup node to start the consensus function. When the consensus node is running normally, the consensus backup node is in the started state but does not perform consensus, execute contracts, blocks, or other blockchain functions. However, after receiving the trigger instruction, the consensus backup node can start the consensus function based on the trigger instruction, and can also start other blockchain functions based on the trigger instruction. Then, the consensus backup node replaces the consensus node and joins the consensus network to participate in the consensus process according to the consensus function.

[0149] It should be noted that, Figure 16 For a detailed description of steps S1210 to S1240 shown, please refer to [link / reference]. Figure 12 Steps S1210 to S1240 shown in the diagram will not be repeated here.

[0150] In this embodiment, the consensus backup node backs up the memory data and ledger data, ensuring that the ledger and memory data are kept almost up-to-date. Therefore, in the event of a consensus node failure, the consensus backup node can quickly resume consensus operations, guaranteeing the reliability of the consensus process.

[0151] For ease of understanding, the data processing method based on a blockchain network provided in the embodiments of this application will be described in detail below: like Figure 17 As shown, the consensus node has a consensus backup node, and the consensus node and the consensus backup node have the same structure. Both the consensus node and the consensus backup node include RPC (Remote Procedure Call), a transaction pool, a message queue, a cache, a consensus module, and a database (DB). The consensus backup node only connects to the master node and has two connection channels: the message queue and the DB. Thus, the consensus node can synchronize data with the consensus backup node through the message queue and the database connection channels.

[0152] It is understandable that consensus nodes and consensus backup nodes can be deployed on different servers in the same data center. Consensus nodes reach consensus with other consensus nodes, while consensus backup nodes can accept queries but do not participate in consensus, execute contracts, blocks, or other blockchain activities.

[0153] After the data in the consensus node is backed up to the consensus backup node, if the consensus node goes down, the consensus backup node can be quickly activated, that is, start consensus and other ledger functions, replace the consensus node and join the consensus network to participate in consensus.

[0154] It is worth noting that in this embodiment, RPC is used to implement remote calls; the transaction pool is used to cache transaction data created by this node and / or transaction data broadcast by other nodes; the cache is used to cache node state data; and the consensus module is used to implement consensus functions.

[0155] Message queues are used to synchronize state data in the cache and transaction data in the transaction pool. The transaction pool data mainly consists of packaged blockchain transactions, while the state data mainly includes request sessions, request states, smart contract query caches, and system state data.

[0156] When synchronizing state data and transaction data, consensus nodes can assign queue sequence numbers to the state data and transaction data, and put the state data and transaction data carrying the queue sequence numbers into the message queue. In this way, the queue sequence numbers can ensure that all data is consumed by the consensus backup nodes.

[0157] It should be noted that, in this embodiment, the state data is stored in a Merkle tree structure in both the consensus node and the consensus backup node, and the state data in the consensus node and the consensus backup node should be the same; therefore, the corresponding Merkle tree structures should also be the same. Figure 18 As shown, Figure 18 This represents the state data of a Merkle tree structure, where L1 to L4 are state data, hash0-0, hash0-1, hash1-0, and hash1-1 are the hash values ​​of L1 to L4 respectively, hash0 is the hash value obtained by hashing hash0-0 and hash0-1, hash1 is the hash value obtained by hashing hash1-0 and hash1-1, and the top hash is the Merkle root.

[0158] When the state data changes, such as when L3 changes, the consensus node will put the changed L3 data into the message queue, and will also put the new Merkle root after the state data change into the message queue. The new Merkle root is the root of the Merkle tree obtained by the consensus node rehashing based on the changed L3. After the consensus backup node synchronizes and obtains the changed L3 data, the consensus backup node will also rehash based on the changed L3 to recalculate hash1-0', and then obtain hash1' through hash1-0' and hash1-1. Then, it will obtain a target Merkle root through hash0 and hash1'. The target Merkle root is then compared with the new Merkle root in the message queue. If the target Merkle root is consistent with the new Merkle root, it means that the state data in the consensus node is consistent with the state data in the consensus backup node.

[0159] In this embodiment, the various data in the message queue are not executed or saved to disk on the consensus backup node, but only exist in memory. The database is used to store the blockchain transaction ledger, and the consensus node and the consensus backup node synchronize the transaction ledger of the consensus node's database to the consensus backup node through database master-slave synchronization. For example, the consensus node and the consensus backup node adopt master-slave synchronization based on LevelDB format data to ensure that the data of the consensus backup node is synchronized to the consensus node in real time.

[0160] It's worth noting that neither message queues nor database backups require real-time data synchronization, but they do require data integrity. This means that consensus nodes don't necessarily need to be synchronized to the latest block for consensus nodes to continue. However, each synchronized block must either be stored completely or not at all. This is because, in the event of a failure, given the multi-node consensus nature of blockchain, consensus backup nodes can quickly start. If a small number of blocks are lagging behind, the lagging synchronization mechanism of the consensus nodes will be used to synchronize with other consensus nodes.

[0161] This solution provides a data processing method that simultaneously performs two methods: memory data synchronization and database master-slave synchronization. This keeps the consensus backup node in near-updated ledger and node status in real time. In the event of a consensus node failure, the consensus backup node can be quickly activated to restore the consensus node's consensus operation.

[0162] Based on the aforementioned consensus node and consensus backup node, this application embodiment also provides a data processing method based on a blockchain network, illustrated by taking the interaction between a consensus node and its consensus backup node as an example. Figure 19 As shown, the method includes: S1910, consensus nodes and consensus backup nodes establish message queues and database connection channels.

[0163] S1920, the consensus node obtains the state data cached in the local cache, the transaction data in the local transaction pool, and the transaction ledger in the database.

[0164] S1930. Consensus nodes verify whether the state data, transaction data, and transaction ledger corresponding to the block to be synchronized are complete.

[0165] S1940. If the state data, transaction data, and transaction ledger are complete, the consensus node assigns queue sequence numbers to the state data and transaction data.

[0166] S1950, the consensus node puts the status data and transaction data carrying the queue sequence number into the message queue so that it can be synchronized to the consensus backup node through the message queue.

[0167] S1960, the consensus node synchronizes the transaction ledger to the consensus backup node through database synchronization.

[0168] S1970, the consensus backup node backs up the synchronized state data to the local cache, backs up the transaction data to the local transaction pool, and backs up the transaction ledger to the local database.

[0169] S1980, the consensus backup node receives the trigger instruction and starts the consensus function according to the trigger instruction.

[0170] In this embodiment, message queue synchronization is performed using the state data of the cache and the transaction data of the transaction pool, and database master-slave synchronization is performed using the transaction ledger stored in the database. This allows consensus node data to be backed up quickly, and the consensus backup node is kept in almost the latest ledger and state in real time. If a consensus node crashes, the consensus backup node can be quickly activated to restore the consensus work of the consensus node.

[0171] This application describes an apparatus embodiment that can be used to execute the data processing method based on a blockchain network as described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the above embodiments of the data processing method based on a blockchain network.

[0172] This application provides a data processing device based on a blockchain network. The blockchain network includes consensus nodes, and each consensus node has a consensus backup node, such as... Figure 20 As shown, this data processing device based on a blockchain network can be deployed in a consensus node. The device includes: The first establishment module 2010 is used to establish a first connection channel and a second connection channel with the consensus backup node. The first connection channel and the second connection channel correspond to different data synchronization methods. The synchronization module 2020 is used to synchronize the memory data written in the local memory of the consensus node to the consensus backup node for memory data backup through the first connection channel; The synchronization module 2020 is used to synchronize the transaction ledger stored in the local database of the consensus node to the consensus backup node for backup of the transaction ledger through the second connection channel.

[0173] In one embodiment of this application, based on the aforementioned scheme, the synchronization module 2020 is further used to obtain the state data cached in the local cache of the consensus node and the transaction data written in the local transaction pool of the consensus node; put the state data and transaction data into a message queue, and synchronize the state data and transaction data to the consensus backup node through the message queue for backup of the state data and transaction data.

[0174] In one embodiment of this application, based on the aforementioned scheme, the synchronization module 2020 is further used to verify whether the status data and transaction data corresponding to the block to be synchronized are complete; if the status data and transaction data are complete, the status data and transaction data are placed in the message queue.

[0175] In one embodiment of this application, based on the aforementioned scheme, the synchronization module 2020 is further used to obtain the queue sequence numbers corresponding to the state data and transaction data respectively; and to put the state data and transaction data into the message queue according to the queue sequence number, so that the consensus backup node can check whether the synchronized data is complete according to the queue sequence number.

[0176] In one embodiment of this application, based on the aforementioned scheme, the state data is backed up in the consensus backup node in a Merkle tree structure; the synchronization module 2020 is further used to obtain the changed state data if the state data changes; and to put the changed data and the new Merkle root after the state data change into a message queue so that the consensus backup node can back up the changed data and verify the consistency of the backed-up state data according to the changed data and the new Merkle root.

[0177] In one embodiment of this application, based on the aforementioned scheme, the synchronization module 2020 is further used to synchronize the transaction ledger stored in the local database to the consensus backup node for backup through a database master-slave synchronization method.

[0178] This application also provides a data processing device based on a blockchain network. The blockchain network includes consensus nodes, and each consensus node has a consensus backup node. The device is deployed in the consensus backup node, such as... Figure 21 As shown, the device includes: The second establishment module 2110 is used to establish a first connection channel and a second connection channel with the consensus node. The first connection channel and the second connection channel correspond to different data synchronization methods. The receiving module 2120 is used to receive memory data written to the local memory of the consensus node through the first connection channel. The receiving module 2120 is also used to receive the transaction ledger stored in the local database of the consensus node synchronized by the consensus node through the second connection channel; Backup module 2130 is used to back up memory data and transaction ledger.

[0179] In one embodiment of this application, based on the aforementioned scheme, the memory data written in the local memory of the consensus node includes state data cached in the local cache and transaction data written in the local transaction pool; the receiving module 2120 is further configured to receive state data and transaction data through a message queue; the backup module is further configured to back up the state data to the local cache of the consensus backup node and back up the transaction data to the local transaction pool of the consensus backup node.

[0180] In one embodiment of this application, based on the aforementioned scheme, the apparatus further includes a verification module. The verification module is used to generate a Merkle tree of state data in the local cache of the consensus backup node; receive changed state data and a new Merkle root after the state data changes through a message queue; back up the changed data to the local cache of the consensus backup node; calculate the target Merkle root based on the changed data, and compare the target Merkle root with the new Merkle root to verify whether the state data in the local cache of the consensus backup node is consistent with the state data in the consensus node based on the comparison result.

[0181] In one embodiment of this application, based on the aforementioned scheme, the receiving module 2120 is further configured to receive the transaction ledger through a database master-slave synchronization method; the backup module is further configured to back up the transaction ledger to the local database of the consensus backup node.

[0182] In one embodiment of this application, based on the aforementioned scheme, the device further includes a replacement module, which is used to receive a trigger instruction sent by a third-party node, the trigger instruction being sent when the consensus node crashes; and to start the consensus function according to the trigger instruction, so as to replace the consensus node in the consensus process according to the consensus function of the consensus backup node.

[0183] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module and unit performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0184] Embodiments of this application also provide an electronic device, including one or more processors and a storage device, wherein the storage device is used to store one or more computer programs, which, when executed by one or more processors, enable the electronic device to implement the above-described data processing method based on a blockchain network.

[0185] Figure 22 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0186] It should be noted that, Figure 22The computer system 2200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application, wherein the electronic device may be a terminal or a server.

[0187] like Figure 22 As shown, the computer system 2200 includes a central processing unit (CPU) 2201, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on a program stored in read-only memory (ROM) 2202 or a program loaded from storage portion 2208 into random access memory (RAM) 2203. Various programs and data required for system operation are also stored in RAM 2203. The CPU 2201, ROM 2202, and RAM 2203 are interconnected via bus 2204. An input / output (I / O) interface 2205 is also connected to bus 2204.

[0188] In some embodiments, the following components are connected to the I / O interface 2205: an input section 2206 including a keyboard, mouse, etc.; an output section 2207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 2208 including a hard disk, etc.; and a communication section 2209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 2209 performs communication processing via a network such as the Internet. A drive 2210 is also connected to the I / O interface 2205 as needed. A removable medium 2211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 2210 as needed so that computer programs read from it can be installed into the storage section 2208 as needed.

[0189] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 2209, and / or installed from removable medium 2211. When the computer program is executed by processor (CPU) 2201, it performs various functions defined in the system of this application.

[0190] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory, flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0191] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and a computer program.

[0192] The units or modules described in the embodiments of this application can be implemented in software or hardware, and can also be located in a processor. The names of these units or modules do not necessarily limit the specific unit or module itself.

[0193] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0194] Another aspect of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of an electronic device reads the computer program from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the methods described above in the various embodiments.

[0195] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0196] Other embodiments of this application will readily conceive of by considering the specification and practicing the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0197] The above content is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A data processing method based on a blockchain network, characterized in that, The blockchain network includes consensus nodes, and each consensus node has a consensus backup node. The method includes: Establish a first connection channel and a second connection channel with the consensus backup node, wherein the first connection channel and the second connection channel correspond to different data synchronization methods; The memory data written in the local memory of the consensus node is synchronized to the consensus backup node through the first connection channel to back up the memory data. The memory data written in the local memory of the consensus node includes state data cached in the local cache and transaction data written in the local transaction pool. The transaction ledger stored in the local database of the consensus node is synchronized to the consensus backup node through the second connection channel to back up the transaction ledger.

2. The method according to claim 1, characterized in that, The step of synchronizing the memory data written to the local memory of the consensus node to the consensus backup node through the first connection channel to back up the memory data includes: The status data and the transaction data are placed in a message queue, and the status data and the transaction data are synchronized to the consensus backup node through the message queue to back up the status data and the transaction data.

3. The method according to claim 2, characterized in that, The step of placing the status data and the transaction data into the message queue includes: Verify whether the status data and transaction data corresponding to the block to be synchronized are complete; If both the status data and the transaction data are complete, then the status data and the transaction data are placed into the message queue.

4. The method according to claim 3, characterized in that, The step of placing the status data and the transaction data into the message queue includes: Obtain the queue sequence numbers corresponding to the status data and the transaction data respectively; The status data and transaction data are placed into the message queue according to the queue sequence number, so that the consensus backup node can verify the integrity of the synchronized data based on the queue sequence number.

5. The method according to claim 2, characterized in that, The state data is backed up in the consensus backup node in a Merkle tree structure; After placing the status data and the transaction data into the message queue, the method further includes: If the status data changes, then the change data of the status data is obtained; The changed data and the new Merkle root after the change in the state data are placed into the message queue so that the consensus backup node backs up the changed data and verifies the consistency of the backed-up state data based on the changed data and the new Merkle root.

6. The method according to claim 1, characterized in that, The step of synchronizing the transaction ledger stored in the local database of the consensus node to the consensus backup node for backup via the second connection channel includes: The transaction ledger stored in the local database is synchronized to the consensus backup node for backup using a database master-slave synchronization method.

7. A data processing method based on a blockchain network, characterized in that, The blockchain network includes consensus nodes, and each consensus node has a consensus backup node. The method includes: Establish a first connection channel and a second connection channel with the consensus node, wherein the first connection channel and the second connection channel correspond to different data synchronization methods; The first connection channel receives memory data written to the local memory of the consensus node, which is synchronized by the consensus node. The memory data written to the local memory of the consensus node includes state data cached in the local cache and transaction data written in the local transaction pool. The transaction ledger stored in the local database of the consensus node, synchronized by the consensus node, is received through the second connection channel. The memory data and the transaction ledger are backed up.

8. The method according to claim 7, characterized in that, The step of receiving memory data written to the local memory synchronized by the consensus node through the first connection channel includes: The status data and transaction data are received via a message queue; The backup of the memory data and the transaction ledger includes: The state data is backed up to the local cache of the consensus backup node, and the transaction data is backed up to the local transaction pool of the consensus backup node.

9. The method according to claim 8, characterized in that, After backing up the state data to the local cache of the consensus backup node, the method further includes: A Merkle tree of the state data is generated in the local cache of the consensus backup node; The message queue receives the change data of the state data and the new Merklegen after the change of the state data. The changed data is backed up to the local cache of the consensus backup node; The target Merkle root is calculated based on the changed data, and the target Merkle root is compared with the new Merkle root to verify whether the state data in the local cache of the consensus backup node is consistent with the state data in the consensus node.

10. The method according to claim 7, characterized in that, The step of receiving the transaction ledger stored in the consensus node database synchronized by the consensus node through the second connection channel includes: The transaction ledger is received via database master-slave synchronization. The backup of the memory data and the transaction ledger includes: The transaction ledger is backed up to the local database of the consensus backup node.

11. The method according to any one of claims 7 to 10, characterized in that, After backing up the memory data and the transaction ledger, the method further includes: Receive a trigger command sent by a third-party node, the trigger command being sent when the consensus node fails; The consensus function is activated according to the triggering instruction, so as to replace the consensus node in the consensus process according to the consensus function of the consensus backup node.

12. A data processing device based on a blockchain network, characterized in that, The blockchain network includes consensus nodes, each with a consensus backup node, and the device deployed within the consensus node includes: The first establishment module is used to establish a first connection channel and a second connection channel with the consensus backup node, wherein the first connection channel and the second connection channel correspond to different data synchronization methods; The synchronization module is used to synchronize the memory data written in the local memory of the consensus node to the consensus backup node for backup of the memory data through the first connection channel, wherein the memory data written in the local memory of the consensus node includes state data cached in the local cache and transaction data written in the local transaction pool. The synchronization module is used to synchronize the transaction ledger stored in the local database of the consensus node to the consensus backup node for backup of the transaction ledger through the second connection channel.

13. A data processing device based on a blockchain network, characterized in that, The blockchain network includes consensus nodes, each consensus node having a consensus backup node, and the device deployed in the consensus backup node includes: The second establishment module is used to establish a first connection channel and a second connection channel with the consensus node, wherein the first connection channel and the second connection channel correspond to different data synchronization methods; The receiving module is configured to receive memory data written to the local memory of the consensus node synchronized by the consensus node through the first connection channel, wherein the memory data written to the local memory of the consensus node includes state data cached in the local cache and transaction data written in the local transaction pool. The receiving module is also used to receive the transaction ledger stored in the local database of the consensus node synchronized by the consensus node through the second connection channel; The backup module is used to back up the memory data and the transaction ledger.

14. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the method of any one of claims 1 to 6, or the method of any one of claims 7 to 11.

15. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the processor of the electronic device, causes the electronic device to perform the method of any one of claims 1 to 6, or the method of any one of claims 7 to 11.

16. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from and executes the computer program to cause the electronic device to perform the method of any one of claims 1 to 6, or the method of any one of claims 7 to 11.

Images