CN112685505B

CN112685505B - Transaction data processing method and device, computer equipment and storage medium

Info

Publication number: CN112685505B
Application number: CN202110020604.2A
Authority: CN
Inventors: 朱耿良
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-01-07
Filing date: 2021-01-07
Publication date: 2022-06-24
Anticipated expiration: 2041-01-07
Also published as: CN112685505A

Abstract

The embodiment of the application discloses a transaction data processing method, a device, computer equipment and a storage medium, wherein the method comprises the following steps: sending a block synchronization request to a consensus node belonging to a core consensus network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the block synchronization request is used for indicating the consensus node to generate the structure information of the compact block corresponding to the block to be synchronized; the structure information includes a target transaction identifier; when receiving the structural information forwarded by the consensus node through the agent node, acquiring a target transaction identifier; determining a local transaction identifier corresponding to first local transaction data in a first node cache, performing block synchronization on a block to be synchronized based on the target transaction identifier and the local transaction identifier, and performing data clearing on the first local transaction data when the block synchronization is completed. By adopting the embodiment of the application, the repeated transmission of the transaction data between the core consensus network and the service network can be reduced.

Description

Transaction data processing method and device, computer equipment and storage medium

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a method and an apparatus for processing transaction data, a computer device, and a storage medium.

Background

In a traditional blockchain deployment, the blockchain network is often a unified peer-to-peer network (i.e., P2P network), i.e., node peering. The blockchain nodes in the blockchain network can broadcast transaction data generated by executing transaction services to the core consensus network, so that the consensus nodes in the core consensus network can uplink the transaction data. For example, a blockchain node (e.g., node a) may broadcast transaction data (e.g., transaction data x) generated by performing a certain transaction service to a consensus node (e.g., node B) to cause node B to write a target block including transaction data x into a blockchain.

It is understood that, here, both node a and node B belong to a single blockchain network, and when node a in the blockchain network needs to request for synchronization of a block, a block synchronization request may be sent to a consensus node (e.g., the aforementioned node B) in the blockchain network, which participates in consensus. At this time, the node B may determine a block to be synchronized (e.g., the aforementioned target block including the transaction data x) in the blockchain of the blockchain network, and may send the target block to the node a to complete the block synchronization. It should be understood that, in the process of requesting to write the target block including the transaction data x into the blockchain, the transaction data x is frequently broadcast between each identified node, but after the target block is successfully written into the blockchain, when the blockchain is synchronized between the nodes in the blockchain network (for example, the node B performs the blockchain synchronization to the node a), the node B returns the transaction data x including the complete transaction data to the node a again, so that the repeated transmission of the same transaction data (the transaction data x) in the whole blockchain network is increased.

Disclosure of Invention

Embodiments of the present application provide a transaction data processing method, an apparatus, a computer device, and a storage medium, which may reduce repeated transmission of transaction data between a core consensus network and a service network.

One aspect of the embodiments of the present application provides a transaction data processing method, including:

sending a block synchronization request to a consensus node belonging to a core consensus network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the service network is a network where a first service node requesting to send a block synchronization request is located; the block synchronization request is used for indicating the consensus node to generate the structural information of the compact block corresponding to the block to be synchronized; the structure information includes a target transaction identifier; the target transaction identifier is determined by the consensus node after the initial transaction data is subjected to hash identification conversion;

when receiving the structural information forwarded by the consensus node through the agent node, acquiring a target transaction identifier in the structural information;

determining a local transaction identifier corresponding to first local transaction data in a first node cache, performing block synchronization on a block to be synchronized based on the target transaction identifier and the local transaction identifier, and performing data clearing on the first local transaction data when the block synchronization is completed.

An aspect of an embodiment of the present application provides a transaction data processing apparatus, including:

the block synchronization request sending module is used for sending a block synchronization request to the consensus node belonging to the core consensus network through the proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the service network is a network where a first service node requesting to send a block synchronization request is located; the block synchronization request is used for indicating the consensus node to generate the structure information of the compact block corresponding to the block to be synchronized; the structure information includes a target transaction identifier; the target transaction identifier is determined after the consensus node performs hash identification conversion on the initial transaction data;

the target identifier acquisition module is used for acquiring a target transaction identifier in the structural information when the structural information forwarded by the consensus node through the agent node is received;

and the data clearing module is used for determining a local transaction identifier corresponding to the first local transaction data in the first node cache, performing block synchronization on the block to be synchronized based on the target transaction identifier and the local transaction identifier, and performing data clearing on the first local transaction data when the block synchronization is completed.

Wherein, the device still includes:

the initial transaction determining module is used for acquiring a transaction service request sent by the user terminal, executing the transaction service requested by the user terminal based on the transaction service request and obtaining initial transaction data according to a transaction execution result of the transaction service;

the initial transaction adding module is used for sending initial transaction data to the consensus node through the proxy node based on the compact block connection mode and adding the initial transaction data to the initial transaction data set corresponding to the first node cache; the dense block connection mode is used for instructing the consensus node to take the target block as the block to be synchronized and generate the structural information of the dense block corresponding to the block to be synchronized when the target block containing the initial transaction data is written into the target block chain of the core consensus network.

Wherein, the device still includes:

the target transaction set determining module is used for obtaining a target transaction data set corresponding to the first node cache when the initial transaction data is added to the initial transaction data set corresponding to the first node cache;

a cochain result receiving module, configured to receive a cochain failure result forwarded by the common node through the proxy node when the common node fails to write the target block including the initial transaction data into a target block chain of the core common network;

and the initial transaction deleting module is used for deleting the initial transaction data in the target transaction data set corresponding to the first node cache based on the uplink failure result.

The first service node is a light weight node;

the block synchronization request sending module comprises:

a block synchronization request generation unit, configured to obtain a block hash value corresponding to a block header having a largest block generation timestamp from a local block chain of the first service node, and generate a block synchronization request for instructing a consensus node in the core consensus network to perform block synchronization based on the block hash value;

the block synchronization request sending unit is used for acquiring the node identification information of the first service node and sending the node identification information and the block synchronization request to the proxy node so that the proxy node forwards the block synchronization request to the consensus node according to the legal verification result; the legal verification result is obtained when the agent node does not find the illegal node identification which is the same as the node identification information in the illegal node list.

Wherein, the target identifier acquisition module comprises:

the encryption information acquisition unit is used for acquiring system encryption data information sent by the proxy node; the system encryption data information is obtained by the proxy node through encrypting the structure information and the signature information through a system public key of the service network; the signature information is obtained after the agent node signs the structural information through a node private key of the agent node when the agent node obtains the structural information sent by the consensus node;

the decryption processing unit is used for decrypting the system encrypted data information through a system private key corresponding to the system public key to obtain structural information and signature information;

the signature verification unit is used for acquiring a node public key of the proxy node, verifying the signature of the signature information based on the node public key and obtaining a signature verification result;

and the target identifier acquisition unit is used for acquiring a target transaction identifier corresponding to the initial transaction data from the structural information when the signature verification result indicates that the signature verification is successful.

The target transaction identifier is determined by the consensus node after the initial transaction data is subjected to Hash identification conversion based on an identifier determination rule;

this data is clear to divide the module and is included:

the identification conversion unit is used for acquiring an identifier determination rule, and performing hash identification conversion on first local transaction data in a first node cache of a first service node based on the identifier determination rule to obtain a local transaction identifier corresponding to the first local transaction data;

the identification comparison unit is used for comparing the local transaction identifier with the target transaction identifier to obtain a comparison result;

the transaction determining unit is used for taking local transaction data corresponding to the local transaction identifier in the first node cache as first key transaction data for verifying the to-be-synchronized block when the comparison result indicates that the local transaction identifier is the same as the target transaction identifier;

and the deleting unit is used for carrying out block synchronization on the block to be synchronized based on the first key transaction data and the structure information, and deleting the first local transaction data in the first node cache when the block synchronization is finished.

Wherein the identifier determination rule comprises: a first hash rule and a second hash rule; the first hash rule is different from the second hash rule;

the identification conversion unit includes:

the first hash conversion subunit is configured to perform, based on a first hash rule in the identifier determination rule, first hash conversion on first local transaction data in a first node cache of the first service node, to obtain a first hash value corresponding to the first local transaction data;

and the second hash conversion subunit is configured to perform second hash conversion on the first hash value based on a second hash rule to obtain a second hash value corresponding to the first local transaction data, and obtain a local transaction identifier corresponding to the first local transaction data based on the second hash value and the number of hash bytes associated with the second hash rule.

Wherein the deletion unit includes:

the acquisition subunit is used for acquiring the block header information and the Merckel path of the block to be synchronized from the structure information;

the to-be-compared tree root determining subunit is used for acquiring a key transaction hash value corresponding to the first key transaction data and a path hash value in the Merckel path, and determining a to-be-compared tree root of the to-be-synchronized block;

the verification result determining subunit is used for obtaining a verification result of the block to be synchronized based on the Mercker tree root in the block header information and the tree root to be compared;

and the deleting subunit is used for carrying out block synchronization on the block to be synchronized if the verification result indicates that the verification is successful, and deleting the first local transaction data in the first node cache when the block synchronization is finished.

Wherein the delete subunit is further configured to:

if the verification result indicates that the verification is successful, obtaining predicted transaction data from the structural information; predicting transaction data which is selected by the consensus node based on the intelligent contract and is related to the first service node in all transaction data in the block to be synchronized;

the first critical transaction data, the predicted transaction data, and the blockhead information are synchronized to a local blockchain of the first service node.

The service network comprises a second service node, wherein the second service node is a node in the same service mechanism list maintained by the first service node;

the device also includes:

the first sending module is used for sending a transaction data acquisition request carrying the target transaction identifier to the second service node when the comparison result indicates that the local transaction identifier is different from the target transaction identifier; the transaction data acquisition request is used for indicating the second service node to obtain a data query result associated with the target transaction identifier in second local transaction data in a second node cache;

the data query result receiving module is used for receiving the data query result returned by the second service node;

and the first determining module is used for taking the second local transaction data as second key transaction data for verifying the to-be-synchronized block if the data query result indicates that the second local transaction data corresponding to the target transaction identifier exists in the second node cache.

Wherein, the device still includes:

the clearing notice generating module is used for carrying out block synchronization on the block to be synchronized based on the second key transaction data and the structural information, and generating a data clearing notice based on the second key transaction data when the block synchronization is finished;

and the score clearing notification sending module is used for sending the data score clearing notification to the second service node so that the second service node deletes the second key transaction data in the cache of the second node.

Wherein, the device still includes:

the second sending module is used for sending the transaction data acquisition request to the consensus node through the proxy node if the data query result indicates that second local transaction data corresponding to the target transaction identifier does not exist in the second node cache; the transaction data acquisition request is used for indicating the consensus node to acquire target transaction data corresponding to the target transaction identifier in the block to be synchronized and sending the target transaction data to the agent node;

the second determining module is used for receiving the target transaction data forwarded by the consensus node through the proxy node and taking the target transaction data as third key transaction data for verifying the block to be synchronized;

and the block synchronization module is used for carrying out block synchronization on the block to be synchronized based on the third key transaction data and the structural information.

An aspect of an embodiment of the present application provides a computer device, including: a processor and a memory;

the processor is connected to the memory, wherein the memory is used for storing a computer program, and when the computer program is executed by the processor, the computer device is caused to execute the method provided by the embodiment of the application.

An aspect of the embodiments of the present application provides a computer-readable storage medium, which stores a computer program, where the computer program is adapted to be loaded and executed by a processor, so as to enable a computer device having the processor to execute the method provided by the embodiments of the present application.

An aspect of an embodiment of the present application provides a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to execute the method provided by the embodiment of the application.

In this embodiment of the present application, when performing block synchronization, a first service node in a service network may send a block synchronization request to a consensus node in a core consensus network through a proxy node for performing network isolation on the core consensus network and the service network, so that the consensus node determines structure information of a dense block corresponding to a block to be synchronized. It can be understood that, when the first service node performs block synchronization, it is not necessary to receive the block to be synchronized including all transaction data, but receive the structure information of the compact block corresponding to the block to be synchronized, like a conventional block chain deployment manner. Further, the first service node may obtain a target transaction identifier representing the initial transaction data from the structure information instead of the complete initial transaction data. The initial transaction data refers to transaction data generated by the first service node when executing transaction service. At this time, the first service node may determine a local transaction identifier corresponding to the first local transaction data in the first node cache, so as to query the first node cache for the transaction data corresponding to the target transaction identifier, so as to reduce data traffic during data transmission. It is to be appreciated that the first service node can block synchronize the block to be synchronized based on the local transaction identifier and the target transaction identifier, and upon completion of the block synchronization, can data-liquidate the first local transaction data. Since the first node cache in the embodiment of the present application may store transaction data (for example, initial transaction data) generated by the first service node, when the first service node performs block synchronization, it is not necessary to synchronize complete transaction data from the core consensus network again, and thus repeated transmission of the transaction data between the core consensus network and the service network may be effectively reduced.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic diagram of a hierarchical structure of a blockchain network according to an embodiment of the present disclosure;

fig. 2 is a schematic view of a scenario for performing data interaction according to an embodiment of the present application;

FIG. 3 is a schematic flow chart diagram illustrating a transaction data processing method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a scenario for sending initial transaction data according to an embodiment of the present application;

fig. 5 is a scene schematic diagram illustrating generation of structure information of a dense block corresponding to a block to be synchronized according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram illustrating a scenario of obtaining a target transaction identifier according to an embodiment of the present application;

FIG. 7 is a schematic flow chart diagram illustrating a transaction data processing method according to an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of a scenario for receiving a data query result according to an embodiment of the present application;

fig. 9 is a system architecture diagram in a block chain electronic ticket scenario according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a transaction data processing device according to an embodiment of the present application;

fig. 11 is a schematic diagram of a computer device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Referring to fig. 1, fig. 1 is a schematic diagram of a hierarchical structure of a blockchain network according to an embodiment of the present disclosure. The blockchain network hierarchy shown in fig. 1 may be applied to a blockchain system, which may include a proxy node (e.g., proxy node 10), a first blockchain system, and a second blockchain system. The first blockchain system and the second blockchain system may each include one or more nodes, and the number of nodes is not limited herein. As shown in fig. 1, the first blockchain system may specifically include a node 110a, a node 110b, a node 110c, …, and a node 110 n. The second blockchain system may specifically include node 120a, node 120b, node 120c, …, node 120 n.

The blockchain network corresponding to the first blockchain system may be referred to as a service network (i.e., witness network), and a node in the service network may be referred to as a service node, where the service node is mainly used to execute a transaction service to obtain transaction data associated with the transaction service. It is understood that the service node does not need to participate in the accounting consensus, but can obtain the block header data and the partial authorization visible block data from the core consensus network by means of identity authentication. The blockchain network corresponding to the second blockchain system may be referred to as a core consensus network. Nodes in the core consensus network may be referred to as consensus nodes (i.e., accounting nodes), which may run a block chain consensus protocol. The agent node shown in fig. 1 may be used to perform network isolation on the service network and the core consensus network, where the agent node 10 may be an independent physical server, may also be a server cluster or a distributed system formed by a plurality of physical servers, and may also be a cloud server that provides basic cloud computing services such as cloud services, a cloud database, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, a CDN, and a big data and artificial intelligence platform, which is not limited herein. The proxy node 10 may perform network layering on a Peer-To-Peer (Peer To Peer, abbreviated as P2P) network To form a layered structure such as a "service network-core consensus network", so as To improve the confidentiality and security of data on a block chain.

In the embodiment of the present application, the proxy node, the service node, and the consensus node may be collectively referred to as a blockchain node in a blockchain network. It is to be understood that the blockchain node may be a server accessing the blockchain network, or may be a user terminal accessing the blockchain network, and a specific form of the blockchain node is not limited herein.

It will be appreciated that the nodes in the blockchain network shown in fig. 1 (e.g., bitcoin network or ethernet network) have the following functions: wallet, blockchain database, network routing. Each node has a routing function, but other functions are not necessarily all, and a general bitcoin core node includes the above functions. Such core nodes may participate in checking, broadcasting transaction data, and tile information, and may discover and maintain connections with other nodes. The core Node will contain a complete blockchain database, including all transaction data, such a Node containing all functions is also called a Full Node (e.g., a consensus Node as shown in fig. 1). Other nodes store only a portion of the blockchain database, typically only the blockhead and transaction data associated with their own node, and not the complete transaction data. They perform transaction Verification by means of "Simplified transaction Verification (SPV), such nodes may be referred to as Lightweight nodes (Lightweight nodes) or SPV nodes (e.g., service nodes shown in fig. 1).

It is understood that the service network and the core consensus network shown in fig. 1 may be in different network environments, for example, generally, the service node is deployed in the service network in a public network, and the accounting node running the block chain consensus protocol is deployed in a private consensus network, and the service node and the core consensus network may interact with each other through a routing boundary. In the block synchronization process, the transaction identifier (i.e., short transaction ID) used for representing the transaction data is transmitted in the service network instead of the complete transaction data, so that the transaction data can be effectively prevented from being easily tampered by others, and the data privacy security of the service node can be improved.

For convenience of understanding, in the embodiment of the present application, one node may be selected as the first service node for performing block synchronization from among a plurality of nodes in the service network shown in fig. 1. The first service node has the function of sending initial transaction data to the proxy node 10. For example, the embodiment of the present application may use the node 110a shown in fig. 1 as the first service node. In the embodiment of the present application, a local cache of the first service node may be referred to as a first node cache, and local transaction data in the first node cache may be referred to as first local transaction data. It will be appreciated that the first service node may maintain the same service organization list. The same service entity list may include a plurality of service nodes belonging to the same service entity as the first service node. In this embodiment, the service nodes in the same service organization list may be collectively referred to as a second service node. For example, the second service node may be node 110b in the service network shown in fig. 1. In this embodiment of the present application, a local cache of the second service node may be referred to as a second node cache, and local transaction data in the second node cache may be referred to as second local transaction data. In addition, in the core consensus network shown in fig. 1, the node 120a may be used as a consensus node for performing block synchronization to the first service node in the embodiment of the present application. It can be understood that, in the embodiment of the present application, the blockchain of the consensus node in the core consensus network may be referred to as a target blockchain, and the blockchain of the first service node in the service network may be referred to as a local blockchain.

Under a hierarchical structure such as a "service network-core consensus network", a first service node and a consensus node may adopt a compact block (compact block) connection mode, and therefore, when a first service node (e.g., the node 110 a) in the service network performs a synchronization block, a block synchronization request may be sent to a consensus node (e.g., the node 120 a) in the core consensus network through the proxy node 10, so that the consensus node may determine structure information of a compact block corresponding to a block to be synchronized. When receiving the structure information forwarded by the proxy node, the first service node may obtain the target transaction identifier in the structure information to perform block synchronization on the block to be synchronized, and when completing the block synchronization, perform data clearing on the local transaction data (i.e., the first local transaction data) in the first node cache. Wherein the target transaction identifier (i.e., shortened transaction identifier, txids) may be a short transaction identification (e.g., a short transaction ID having 6 bytes) used to represent the initial transaction data. The initial transaction data here refers to transaction data generated by the first service node when executing the transaction service, and is stored in the first node cache. Therefore, when the first service node is in block synchronization, the target transaction identifier is transmitted in the service network instead of the complete initial transaction data, so that repeated transmission of the transaction data between the core consensus network and the service network can be effectively reduced.

For easy understanding, please refer to fig. 2, and fig. 2 is a schematic diagram of a scenario for performing data interaction according to an embodiment of the present application. As shown in fig. 2, the proxy node 20B in the embodiment of the present application may be used to perform network isolation between a service network and a core consensus network, and the proxy node 20B may be the proxy node 10 shown in fig. 1. The service node 20A in this embodiment may be a service node (e.g., a first service node) that needs to perform block synchronization, and the service node 20A may be any one of the nodes in the service network shown in fig. 1, for example, the node 110A. The consensus node 20C in this embodiment may be a consensus node for determining a block to be synchronized, and the consensus node 20C may be any one of the nodes in the core consensus network shown in fig. 1, for example, the node 120 a.

It should be understood that the service node 20A may execute the transaction service to obtain the initial transaction data according to the transaction execution result of the transaction service, and further may send the initial transaction data to the agent node 20B, so that the agent node 20B sends the initial transaction data to the core consensus network for broadcasting. The transaction service may be an asset transfer service, which is to transfer virtual assets such as bitcoin, ether house, game gold, game diamond, and electronic ticket. At the same time, the service node 20A may also add initial transaction data to the node cache 200 shown in fig. 2. Node cache 200 (i.e., the first node cache) herein may refer to a local cache of service node 20A. It is understood that a consensus node (e.g., the consensus node 20C) in the core consensus network may perform a packing process on the initial transaction data to generate a to-be-verified block, and then the to-be-verified block may be used as a target block when the to-be-verified block achieves consensus, so as to successfully write the to-be-verified block into a target block chain of the core consensus network.

As shown in fig. 2, the service node 20A may send a block synchronization request to the proxy node 20B, so that the proxy node 20B sends the block synchronization request to the consensus node 20C in the core consensus network. At this time, the consensus node 20C may determine a block to be synchronized (e.g., the block to be synchronized 200 x) in the target block chain in the core consensus network based on the block synchronization request. Further, in order to effectively reduce the data traffic when the transaction data is frequently broadcast between the core consensus network and the service network and data transmission, the consensus node 20C and the service node 20A may employ a dense block connection mode, and during the block synchronization process, the consensus node 20C may transmit the structure information (e.g., the structure information 200 y) of the dense block corresponding to the block to be synchronized 200x, so as to perform data sorting on the node cache 200 when the service node 20A completes the block synchronization. It is understood that the structure information 200y may include the block header information of the block to be synchronized 200x, the target transaction identifier, and the predicted transaction data. The target transaction identifier may be determined by the consensus node 20C after performing hash identification conversion on the initial transaction data; the target transaction identifier may be a hash value of a shorter byte (e.g., 6 bytes), which can effectively reduce traffic data during data transmission, so that the service node 20A receiving the target transaction identifier can reduce data processing pressure, thereby effectively preventing denial of service attacks. The predicted transaction data may be the transaction data associated with the service node 20A, which is screened by the consensus node 20C based on the smart contract, among all transaction data in the block to be synchronized.

It will be appreciated that the consensus node 20C may send the structure information 200y to the service node 20A via the proxy node 20B so that the service node 20A may obtain the target transaction identifier from the structure information 200y, e.g., the target transaction identifier obtained by the service node 20A from the structure information 200y may be the transaction identifier 40f shown in fig. 2.

As shown in fig. 2, before the service node 20A performs data liquidation, a plurality of local transaction data (i.e., the first local transaction data) may be included in the node cache 200. The local transaction data is stored when the service node 20A sends initial transaction data generated by executing the transaction service to the core consensus network through the proxy node 20B for broadcasting. For convenience of illustration, in the embodiment of the present application, 4 local transaction data in the node cache 200 before data clearing may be taken as an example, and specifically may include transaction data 1e, transaction data 2e, transaction data 3e, and transaction data 4 e.

It is understood that service node 20A may perform hash identification conversion on each local transaction data in node cache 200 to obtain a local transaction identifier corresponding to each local transaction data. As shown in FIG. 2, the transaction identifier of transaction data 1e may be transaction identifier 10f, the transaction identifier of transaction data 2e may be transaction identifier 20f, the transaction identifier of transaction data 3e may be transaction identifier 30f, and the transaction identifier of transaction data 4e may be transaction identifier 40 f.

Further, the service node 20A may perform block synchronization on the to-be-synchronized block 200x based on the target transaction identifier and the local transaction identifier, and when the block synchronization is completed, the service node 20A performs data clearing on the local transaction data in the node cache 200. For example, the service node 20A may compare the target transaction identifier with the local transaction identifier to obtain a comparison result. The comparison result may indicate that the transaction identifier 40f in the local transaction identifier is the same as the target transaction identifier, at this time, the service node 20A may obtain the transaction data 4e corresponding to the transaction identifier 40f in the node cache 200, and further may synchronize the to-be-synchronized block 200x based on the transaction data 4e, and when the block synchronization is completed, the service node 20A may delete the transaction data 4e in the node cache 200. In other words, the local transaction data in the node cache 200 after data liquidation may include transaction data 1e, transaction data 2e, and transaction data 3 e.

It should be understood that, in a hierarchical block chain structure of "service network-core consensus network", when the service node 20A in the service network performs data sorting on the local transaction data in the node cache 200, a block synchronization request may be sent to the consensus node 20C in the core consensus network through the proxy node 20B, so that the consensus node 20C determines the to-be-synchronized block 200x based on the block synchronization request. It can be understood that, when the common node 20C performs block synchronization, since the common node 20C and the service node 20A adopt the dense block connection mode, the entire block to be synchronized 200x is not required to be transmitted, but the structure information 200y of the dense block corresponding to the block to be synchronized 200x is transmitted. Further, the service node 20A may obtain the target transaction identifier in the structure information 200y, and further perform block synchronization on the to-be-synchronized block 200x based on the target transaction identifier and the local transaction identifier corresponding to the local transaction data in the node cache 200, so as to perform data sorting on the local transaction data in the node cache 200 when the block synchronization is completed. In other words, the consensus node 20C transmits a short transaction identifier corresponding to the initial transaction data instead of the complete initial transaction data, so that repeated transmission of the transaction data between the core consensus network and the service network can be effectively reduced, and unnecessary network traffic is greatly reduced.

The transaction data processing method according to the embodiment of the present application may perform network layering on the P2P network based on a two-layer blockchain mode, so that the P2P network forms a layered blockchain structure of a service network-core consensus network. When a first service node in the service network is in block synchronization, the structural information of a compact block corresponding to a block to be synchronized, which is determined by a consensus node in the core consensus network, may be obtained by a proxy node performing network isolation on the service network and the core consensus network, and then the block to be synchronized may be block synchronized by a target transaction identifier in the structural information and a local transaction identifier corresponding to first local transaction data in a first node cache, and when block synchronization is completed, a specific implementation manner of performing data sorting on the first local transaction data may be referred to the following embodiments corresponding to fig. 3 to 9.

Further, please refer to fig. 3, wherein fig. 3 is a schematic flow chart of a transaction data processing method according to an embodiment of the present application. As shown in fig. 3, the method may be performed by a first service node in a service network, where the first service node may be a server accessed to the service network or a user terminal accessed to the service network, and a specific form of the first service node is not limited herein. The first service node may be any one of the nodes in the service network shown in fig. 1, e.g., node 110 a. The method may comprise at least the following steps S101-S103:

step S101, sending a block synchronization request to a consensus node belonging to a core consensus network through a proxy node.

In particular, a first service node in the service network may generate a block synchronization request for instructing a consensus node in the core consensus network to perform block synchronization when block synchronization is performed. Meanwhile, the first service node can also acquire the node identification information of the first service node and send the node identification information and the block synchronization request to the proxy node, so that the proxy node forwards the block synchronization request to the common node according to the legal verification result. The valid verification result is obtained when the proxy node does not find the illegal node identifier which is the same as the node identifier information in the illegal node list.

It should be understood that, the first service node in the service network may obtain the transaction service request sent by the user terminal, and further may execute the transaction service requested by the user terminal based on the transaction service request, so as to obtain the initial transaction data according to the transaction execution result of the transaction service. For example, a first service node (e.g., a server corresponding to an application client associated with an electronic ticket) may obtain a transaction service request sent by a user terminal (e.g., terminal device a) corresponding to a consuming user, where the transaction service performed by the transaction service request may be: and transferring the electronic bill (for example, the electronic bill X) obtained by the terminal device A when the equipment is purchased to a corresponding user terminal (for example, the terminal device B) of the enterprise where the consumer user is located. Further, the first service node may execute the asset transfer service based on the transaction service request, and may further obtain initial transaction data according to a transaction execution result of the transaction service.

The first service node and the consensus node in the core consensus network can adopt a compact block connection mode. The dense block connection mode may be used to instruct the consensus node to take the target block as the block to be synchronized and generate the structure information of the dense block corresponding to the block to be synchronized when the target block containing the initial transaction data is written into the target block chain of the core consensus network.

It is to be appreciated that the first service node may send the initial transaction data to the consensus node in the core consensus network through the proxy node based on the tight block connectivity pattern. At the same time, the first service node may add the initial transaction data to the initial transaction data set corresponding to the first node cache. When the first service node adds the initial transaction data to the initial transaction data set corresponding to the first node cache, a target transaction data set corresponding to the first node cache may be obtained.

For ease of understanding, please refer to fig. 4, where fig. 4 is a schematic diagram of a scenario for sending initial transaction data according to an embodiment of the present application. As shown in fig. 4, the proxy node 40B in the embodiment of the present application may be used to perform network isolation between a service network and a core consensus network, and the proxy node 40B may be the proxy node 10 shown in fig. 1. The service node 40A in this embodiment may be a service node (e.g., a first service node) that needs to perform block synchronization, and the service node 40A may be any one of the nodes in the service network shown in fig. 1, for example, the node 110A. The common node 40C in this embodiment may be a common node for determining a block to be synchronized, and the common node 40C may be any one of the nodes in the core common network shown in fig. 1, for example, the node 120 a.

It should be understood that a user terminal having a network connection relationship with the service node 40A may send a transaction service request to the service node 40A. For example, in a game scenario, when a user (e.g., user 1) transfers 10 game coins to another user (e.g., user 2), the user terminal (e.g., user terminal a) corresponding to user 1 may generate a transaction service request sent to service node 40A, so that service node 40A performs this transaction service based on the transaction service request to transfer the 10 game coins to user terminal B. Further, the service node 40A may obtain initial transaction data (e.g., transaction data 44e shown in fig. 4) according to the transaction execution result of the transaction service. At this point, the service node 40A may send the transaction data 44e to the proxy node 40B, so that the proxy node 40B broadcasts the transaction data 44e3e to the consensus node 40C in the core consensus network.

It is understood that while the service node 40A sends the transaction data 44e to the proxy node 40B, the transaction data 44e may be added to the initial transaction data set in the local cache (i.e., the first node cache) of the service node 40A, so as to obtain the target transaction data set in the first node cache. For example, the local cache of service node 40A may be node cache 400 as shown in fig. 4. It should be understood that the initial transaction data set corresponding to the node cache 400 may include a plurality of transaction data, and the embodiment of the present application may take 3 transaction data as an example, and specifically may include transaction data 41e, transaction data 42e, and transaction data 43 e. When business node 40A adds the initial transaction data to node cache 400, the target transaction data set corresponding to node cache 400 may include transaction data 41e, transaction data 42e, transaction data 43e, and transaction data 44 e.

Wherein, the proxy node 40B may perform the authorization verification on the service node 40A upon receiving the transaction data 44 e. The authority verification here may include verifying whether the node identification information of the service node 40A belongs to the node identification in the illegal node list, whether the transaction format of the transaction data 44e is wrong, whether the signature is wrong, or the like. It is understood that the illegal node list may refer to a blacklist stored by the proxy node 40B, and the illegal node corresponding to the illegal node identifier in the illegal node list refers to a detected malicious node, a node reported by another person, a node that sends an abnormal transaction frequency for a certain period of time, and the like.

It is to be appreciated that when the proxy node 40B determines that the service node 40A is an illegitimate node and the transaction format of the transaction data 44e is in error, then the proxy node 40B need not send the transaction data 44e to the consensus node 40C, and the proxy node 40B may generate a data credit notification for sending to the service node 40A based on the transaction data 44 e. The service node 40A, upon receiving the data inventory notification, may delete the transaction data 44e in the node cache 400.

Optionally, when the proxy node 40B confirms that the service node 40A is a valid node and the transaction format of the transaction data 44e is correct, the transaction data 44e may be forwarded to the consensus node 40C, so that the consensus node 40C uplinks the transaction data 44 e. The service node 40A and the consensus node 40C may adopt a dense block connection mode to reduce repeated transmission of transaction data between the core consensus network and the service network, thereby reducing data traffic during data transmission.

It is understood that, when receiving the initial transaction data, the consensus node in the core consensus network may perform a packing process on the initial transaction data to generate a target block to be written into the target block chain. Further, the consensus node may broadcast the target block to a core consensus network to perform consensus on the target block. The consensus node may generate an uplink failure result to the first service node if the consensus node fails to write the target block containing the initial transaction data to the target block chain. Further, the common node may forward the uplink failure result to the first service node through the proxy node, so that the first service node may delete the initial transaction data in the target transaction data set corresponding to the first node cache based on the uplink failure result.

For example, as shown in fig. 4, when the common node 40C fails to write the target block containing the transaction data 44e into the target block chain, the common node 40C may generate a uplink failure result, and may forward the uplink failure result to the service node 40A through the proxy node 40B. Upon receiving the uplink failure result, the service node 40A may delete the transaction data 44e from the target transaction data set corresponding to the node cache 400 shown in fig. 4.

Optionally, when the common node successfully writes the target block containing the initial transaction data into the target block chain, the service node may keep caching until the synchronized block includes the initial transaction data, and may delete the initial transaction data in the target transaction data set corresponding to the first service node.

The first service node in this embodiment may be a full-weight node or a lightweight node, which is not limited herein. It will be appreciated that where the first service node is a quorum node, the local blockchain of the first service node may be the same blockchain as the target blockchain (in a core consensus network). In other words, the local blockchain stores the complete data in the target blockchain, such as all transaction data. It should be understood that, when the blocks are synchronized, the first service node belonging to the full-scale node may obtain, from the local block chain, the block hash value corresponding to the block having the largest block generation timestamp, and may further generate a block synchronization request based on the block hash value.

Optionally, when the first service node is a lightweight node, the local blockchain of the first service node may store a part of the target blockchain (a blockchain in the core consensus network). For example, the local blockchain typically stores a blockhead in the target blockchain and transaction data associated with the first service node. It should be understood that, when block synchronization is performed, the first service node belonging to the lightweight node may obtain, from the local block chain, the block hash value corresponding to the block header having the largest block generation timestamp, and may further generate a block synchronization request based on the block hash value.

The first service node in this embodiment may take a lightweight node as an example, and is used to describe a process of performing data clearing on the first local transaction data in the first node cache of the first service node when the first service node completes block synchronization.

It can be understood that the first service node may obtain node identification information of the first service node, and may further send the node identification information and the generated block synchronization request to the proxy node, so that the proxy node performs permission verification on the first service node to obtain a permission verification result. The authority verification here may include verifying whether the node identification information of the first service node belongs to a node identification in an illegal node list. It is understood that the illegal node list may refer to a blacklist stored by the proxy node, and the illegal node corresponding to the illegal node identifier in the illegal node list refers to a detected malicious node, a node reported by others, a node that sends an abnormal transaction frequency for a certain period of time, and the like.

It can be understood that the proxy node may search the illegal node identifier in the illegal node list, which is the same as the node identifier information of the first service node, to obtain the authority verification result. If the permission verification result indicates that the illegal node identification which is the same as the node identification information is found in the illegal node list, the proxy node can determine that the permission verification result belongs to the illegal verification result, and at the moment, the proxy node can determine that the service node is the illegal node, so that the block synchronization request does not need to be sent to the common node in the core common network. If the authority verification result indicates that the illegal node identification which is the same as the node identification information is not found in the illegal node list, the proxy node can determine that the authority verification result belongs to a legal verification result. At this time, the proxy node may determine that the service node is a legitimate node, and may forward the block synchronization request to a consensus node in the core consensus network.

It should be understood that the block synchronization request may be used to instruct the consensus node to generate structure information of the dense block corresponding to the block to be synchronized. For easy understanding, please refer to fig. 5, and fig. 5 is a schematic view of a scenario for generating structure information of a dense block corresponding to a block to be synchronized according to an embodiment of the present application. As shown in fig. 5, the proxy node 50B in the embodiment of the present application may be used to perform network isolation between a service network and a core consensus network, and the proxy node 50B may be the proxy node 10 shown in fig. 1. The service node 50A in this embodiment may be a service node (e.g., a first service node) that needs block synchronization, and the service node 50A may be any node in the service network shown in fig. 1, for example, the node 110A. The consensus node 50C in this embodiment may be a consensus node for determining a block to be synchronized, and the consensus node 50C may be any node in the core consensus network shown in fig. 1, for example, the node 120 a.

The service node 50A in this embodiment may be a lightweight node, and the local block chain of the service node 50A may store block header information and transaction data associated with the service node 50A, so as to avoid waste of storage space. As shown in fig. 5, the local block chain of the service node 50A may include a block header 1, a block header 2, …, and a block header n. Where n is a positive integer. The common node 50C in the embodiment of the present application is a full node, and a target block chain of the common node 50C may store a complete block. As shown in fig. 5, the target block chain may include (n + 1) blocks, i.e., block 1, block 2, block 3, …, block n, and block (n + 1). Wherein each block includes block header information and block body information. For example, n in the embodiment of the present application may be 4, and the local block chain may include a block header 1, a block header 2, a block header 3, and a block header 4. The target block chain may include block 1, block 2, block 3, block 4, and block 5.

It should be understood that, when performing block synchronization, the service node 50A belonging to the lightweight node may obtain, from the local block chain, the block hash value corresponding to the block header having the largest block generation timestamp, that is, the block hash value corresponding to the block header 4, and may further generate the block synchronization request based on the block hash value corresponding to the block header 4. The service node 50A may also obtain node identification information of the service node 50A, and further may send the node identification information and the generated block synchronization request to the proxy node 50B, so that the proxy node 50B forwards the block synchronization request to the common node 50C according to the result of the legal verification.

It is understood that the consensus node 50C, upon receiving the block synchronization request, may determine the block to be synchronized in the target block chain shown in fig. 5 based on the block hash value carried in the block synchronization request. For example, the block to be synchronized determined by the common node 50C may be block 5. The block information of the block 5 may include block header information and a block body. The block header information may include information such as a hash value of a parent block of the block to be synchronized (i.e., a hash value of a block 4), a block height, a version number, a timestamp, a difficulty value, a random number, and a root of a mercker tree. The tile body may include transaction data packed into tile 5 and a merkel path formed by transaction hash values of the transaction data.

The transaction data in block 5 may include the initial transaction data that was sent by service node 50A, as well as other related transaction data. For example, transaction data 51, transaction data 53, and transaction data 54 may each be initial transaction data that was sent by service node 50A. The transaction data 52 may be transaction data sent by a service node having an association with the service node 50A, and the transaction data 52 is specified in the transaction content to be visible to the service node 50A, in other words, the transaction data 52 is not stored in the node cache of the service node 50A.

Further, consensus node 50C may invoke the smart contract, filter the transaction data associated with business node 50A among all transaction data in block 5, and may refer to the filtered transaction data as predicted transaction data. It will be appreciated that smart contracts are computerised agreements which can enforce the terms of a certain contract, implemented by code deployed on a shared ledger for enforcement when certain conditions are met, for use in completing automated transactions according to actual business requirement code, such as querying the logistic status of goods purchased by a buyer, transferring the buyer's electronic money to a merchant's address after the buyer has signed for goods; of course, intelligent contracts are not limited to executing contracts for trading, but may also execute contracts that process received information.

As shown in fig. 5, the consensus node 50C may invoke a smart contract to obtain a visible list associated with the transaction data 52. Wherein the visible list may include node identifications of nodes that need to store the transaction data 52. It will be appreciated that if the same node identification is found in the visible list as the service node 50A, the consensus node 50C may use the transaction data 52 as predicted transaction data for sending the complete transaction data 52 to the service node 50A.

For ease of understanding, please refer to table 1, where table 1 is a node identification list provided in the embodiments of the present application. As shown in table 1, the node identification list may store node identifications of nodes visible to some transaction data. The node identifier may be an IP (Internet Protocol) address and any other information that can be used to identify the node, and table 1 only illustrates the IP address as an example.

TABLE 1

Node name	Node identification
		Service node a1	117.114.151.174
Service node a2	117.116.189.145
		…	…
Service node AN	119.123.789.258

Further, the consensus node 50C may determine the initial transaction data, e.g., transaction data 51, transaction data 53, and transaction data 54, sent by the service node 50A among all transaction data in block 5. At this time, the consensus node 50C may obtain the identifier determination rule, and perform hash identification conversion on the initial transaction data to obtain the target transaction identifier corresponding to the initial transaction data. For example, the target transaction identifier corresponding to transaction data 51 may be transaction identifier a, the target transaction identifier corresponding to transaction data 53 may be transaction identifier c, and the target transaction identifier corresponding to transaction data 54 may be transaction identifier d. In addition, the consensus node 50C may further obtain a mercker path of the transaction data associated with the service node 50A, that is, mercker paths of the transaction data 51, the transaction data 53, and the transaction data 54, so that the service node 50A checks the to-be-synchronized block when receiving the configuration information 500 y.

At this time, the consensus node 50C may generate structure information (e.g., the structure information 500y shown in fig. 5) of the dense block corresponding to the block 5 based on the block header information, the mercker path, the predicted transaction data, and the target transaction identifier of the block 5. Further, the consensus node 50C may send the structure information 500y to the service node 50A through the proxy node 50B.

Step S102, when the structure information forwarded by the consensus node through the agent node is received, the target transaction identifier in the structure information is obtained.

Specifically, the first service node may obtain system encryption data information sent by the proxy node. The system encryption data information can be obtained by the proxy node through encrypting the structure information and the signature information through a system public key of a service network; the signature information may be obtained by the proxy node signing the structure information through a node private key of the proxy node when the proxy node acquires the structure information sent by the consensus node. Further, the first service node may decrypt the system encrypted data information through a system private key corresponding to the system public key to obtain the structure information and the signature information. The first service node may obtain a node public key of the agent node, and check the signature information based on the node public key to obtain a signature checking result. When the signature verification result indicates that the signature verification is successful, the first service node may obtain the target transaction identifier corresponding to the initial transaction data from the structure information.

For ease of understanding, please refer to fig. 6, where fig. 6 is a schematic diagram of a scenario for obtaining a target transaction identifier according to an embodiment of the present application. As shown in fig. 6, the service node 60A in the embodiment of the present application may be a first service node for performing block synchronization, and the service node 60A may be any one of the service nodes in the service network shown in fig. 1, for example, the node 110A. The consensus node 60C in this embodiment may be configured to determine structure information of a compact block corresponding to a block to be synchronized, where the consensus node 60C may be any one of the nodes in the core consensus network shown in fig. 1, for example, the node 120 a. The proxy node 60B in the embodiment of the present application may be used to perform network isolation between the service network and the core consensus network, and the proxy node 60B may be the proxy node 10 shown in fig. 1.

It should be understood that, since the consensus node 60C and the service node 60A in the embodiment of the present application adopt the dense block connection mode, when receiving the block synchronization request generated by the service node 60A, the consensus node 60C may determine, on the target block chain of the core consensus network, structure information (for example, structure information 600y shown in fig. 6) of a dense block corresponding to a block to be synchronized, and further may send the structure information 600y to the proxy node 60B, so that the proxy node 60B sends the structure information 600y to the service node 60A.

It can be understood that, since the core consensus network is in a relatively secure private cloud, the mutual access of the core consensus network has a consensus mechanism to ensure security, and no additional identity management and network control need to be added, while the service network is generally in a public network and can be accessed by other uncertain network terminals. Therefore, in the process of the proxy node 60B transmitting the configuration information 600y to the service node 60A, strict control is required. In other words, when the proxy node 60B receives the configuration information 600y sent by the consensus node 60C, the proxy node 60B may sign the configuration information 600y based on the node private key of the proxy node 60B to obtain signature information corresponding to the configuration information 600 y. It is understood that the proxy node 60B may perform a hash calculation on the structure information 600y, so as to obtain the digest information h of the structure information 600y, and digitally sign the digest information h based on the node private key of the proxy node 60B, so as to obtain the signature information corresponding to the structure information 600 y. Further, the proxy node 60B may obtain a system public key of the service network, and encrypt the structure information 600y and the signature information to obtain system encrypted data information. At this time, the proxy node 60B may send system encrypted data information to the service node 60A in the service network.

Further, when receiving the system encrypted data information, the service node 60A may decrypt the system encrypted data information through a system private key corresponding to the system public key, so as to obtain the structure information 600y and the signature information. Further, the service node 60A may obtain a node public key of the proxy node 60B, and perform signature verification on the signature information based on the node public key to obtain a signature verification result. It can be understood that the service node 60A may check and sign the digital signature in the signature information based on the node public key of the proxy node 60B to obtain the digest information H of the structure information 600y, and perform hash calculation on the structure information 600y by using the same hash algorithm as that of the proxy node 60B, so as to obtain the digest information H of the structure information 600 y. Further, the service node 60A may compare the digest information H obtained after signature verification with the digest information H obtained by performing hash calculation, so as to obtain a signature verification result. If the signature verification result indicates that the summary information H is different from the summary information H, it can be understood that the service node 60A fails to verify the signature. If the signature verification result indicates that the summary information H is the same as the summary information H, it can be understood that the signature verification of the service node 60A is successful, and thus the structure information 600y can be obtained.

When the result of the signature verification indicates that the signature verification is successful, the service node 60A may obtain the target transaction identifier corresponding to the initial transaction data from the structure information 600 y. For example, if the structure information 600y is the same as the structure information 500y shown in fig. 5, the target transaction identifier acquired by the service node 60A may be the transaction identifier a, the transaction identifier c, and the transaction identifier d shown in fig. 5.

Step S103, determining a local transaction identifier corresponding to the first local transaction data in the first node cache, performing block synchronization on the block to be synchronized based on the target transaction identifier and the local transaction identifier, and performing data sorting on the first local transaction data when the block synchronization is completed.

Specifically, the first service node may obtain the identifier determination rule, and then may perform hash identification conversion on the first local transaction data in the first node cache of the first service node based on the identifier determination rule, so as to obtain a local transaction identifier corresponding to the first local transaction data. Further, the first service node may compare the local transaction identifier with the target transaction identifier to obtain a comparison result. It should be understood that, when the comparison result indicates that the local transaction identifier is the same as the target transaction identifier, the first node may use the local transaction data corresponding to the local transaction identifier in the first node cache as the first key transaction data for verifying the block to be synchronized, and further may perform block synchronization on the block to be synchronized based on the first key transaction data and the structural information, and delete the first local transaction data in the first node cache when the block synchronization is completed.

And the target transaction identifier is determined by the consensus node after the initial transaction data is subjected to hash identification conversion based on the identifier determination rule. Therefore, the first service node may perform hash identifier conversion on the first local transaction data in the first node cache by using the identifier determination rule, so as to obtain a local transaction identifier corresponding to the first local transaction data.

It is to be understood that the identifier determination rule in the embodiment of the present application may include a first hash rule and a second hash rule. The first hash rule here is different from the second hash rule. It can be understood that the first service node may perform a first hash conversion on the first local transaction data based on the first hash rule, to obtain a first hash value corresponding to the first local transaction data. Further, the first service node may perform a second hash conversion on the first hash value based on a second hash rule to obtain a second hash value corresponding to the first local transaction data, and obtain a local transaction identifier corresponding to the first local transaction data based on the second hash value and a hash byte number (e.g., 6 bytes) associated with the second hash rule.

It should be appreciated that the first hash rule and the second hash rule may both be hash functions, also known as hash algorithms, which is a way to create small digital "fingerprints" from any kind of data. The hash function compresses a message or data into a digest so that the amount of data becomes small, fixing the format of the data. This function mixes the data shuffled and recreates a fingerprint called a hash value (or hash value). The hash value is typically represented by a short string of random letters and numbers.

For example, the first hash rule may be SHA256, and the second hash rule may be a SipHash algorithm (e.g., SipHash-2-4). It is understood that the first service node may perform a first hash conversion on the first local transaction data to which the random number is added in a little-endian (little-endian) using SHA256 to obtain a 256-bit (equivalent to an array of 32 bytes) long hash value (i.e., a first hash value). Further, the first service node may use siphorash-2-4 to set the key (k 0/k 1) as the first two small-end 64-bit (corresponding to an array of 8 bytes) integers of the first hash value, respectively, so as to obtain a second hash value corresponding to the first local transaction data. At this time, the first service node may delete the 2 most significant bytes from the second hash value to make it 6 bytes, and may use the hash value of the 6 bytes as the local transaction identifier corresponding to the first local transaction data.

Further, the first service node may compare the local transaction identifier with the target transaction identifier to obtain a comparison result. When the comparison result indicates that the local transaction identifier is the same as the target transaction identifier, the first service node may use the local transaction data corresponding to the local transaction identifier in the first node cache as the first critical transaction data for verifying the to-be-synchronized block.

Further, the first service node may obtain, from the structure information, block header information and a mercker path of the block to be synchronized, obtain a key transaction hash value corresponding to the first key transaction data and a path hash value in the mercker path, and determine a tree root to be compared of the block to be synchronized. At this time, the first service node may obtain a verification result of the block to be synchronized based on the mercker tree root and the tree root to be compared in the block header information. It is to be understood that, when the verification result indicates that the mercker tree root is not consistent with the tree root to be compared, the first service node may consider the verification result to indicate a verification failure. Optionally, when the verification result indicates that the mercker tree root is consistent with the tree root to be compared, the first service node may consider that the verification result indicates that the verification is successful.

If the verification result indicates that the verification is successful, the first service node may perform block synchronization on the to-be-synchronized block, and delete the first local transaction data in the first node cache when the block synchronization is completed. It is to be understood that, if the verification result indicates that the verification is successful, the first service node may obtain the predicted transaction data from the structure information. The predicted transaction data is selected from all transaction data in the block to be synchronized by the consensus node based on the intelligent contract and is associated with the first service node.

It should be understood that if the first service node is a full-scale node, the first service node may reconstruct the block to be synchronized based on the first critical transaction data, the predicted transaction data, and the block header information in the structure information, and may further synchronize the block to be synchronized to the local block chain of the first service node. Optionally, if the first service node is a lightweight node, the first service node may synchronize the first critical transaction data, the predicted transaction data, and the block header information to a local block chain of the first service node.

For example, the target transaction identifier obtained by the first service node (e.g., service node 50A shown in fig. 5) is transaction identifier a, transaction identifier c, and transaction identifier d shown in fig. 5. While the first local transaction data in the first node cache of the service node 50A may be the transaction data in the target transaction data set in the node cache 400 shown in fig. 4. Wherein the service node 50A may determine a local transaction identifier corresponding to the first local transaction data. The local transaction identifier may specifically include a transaction identifier 1f, a transaction identifier 2f, a transaction identifier 3f, and a transaction identifier 4 f. The transaction identifier 1f may be a local transaction identifier corresponding to the transaction data 41e shown in fig. 4, the transaction identifier 2f may be a local transaction identifier corresponding to the transaction data 42e shown in fig. 4, the transaction identifier 3f may be a local transaction identifier corresponding to the transaction data 43e shown in fig. 4, and the transaction identifier 4f may be a local transaction identifier corresponding to the transaction data 44e shown in fig. 4.

The service node 50A may compare the transaction identifier a in the target transaction identifier with the local transaction identifier to obtain a comparison result (e.g., comparison result 1). Here, the comparison result 1 may indicate that the transaction identifier a in the target transaction identifier is the same as the transaction identifier 1f in the local transaction identifier, and at this time, the service node 50A may use, in the local transaction data shown in the node cache 400, the transaction data 41e corresponding to the transaction identifier 1f as the first critical transaction data for verifying the to-be-synchronized block.

Further, the service node 50A may compare the transaction identifier c in the target transaction identifier with the local transaction identifier to obtain a comparison result (e.g., comparison result 2). The comparison result 2 may indicate that the transaction identifier c in the target transaction identifier is the same as the transaction identifier 3f in the local transaction identifier, and at this time, the service node 50A may use, in the local transaction data shown in the node cache 400, the transaction data 43e corresponding to the transaction identifier 3f as the first critical transaction data for verifying the to-be-synchronized block.

Further, the service node 50A may compare the transaction identifier d in the target transaction identifier with the local transaction identifier to obtain a comparison result (e.g., comparison result 3). The comparison result 3 may indicate that the transaction identifier d in the target transaction identifier is the same as the transaction identifier 4f in the local transaction identifier, and at this time, the service node 50A may use, in the local transaction data shown in the node cache 400, the transaction data 44e corresponding to the transaction identifier 4f as the first critical transaction data for verifying the to-be-synchronized block.

The transaction data 41e, the transaction data 43e, and the transaction data 44e may be referred to as first critical transaction data for verifying a block to be synchronized (e.g., the block (n + 1) shown in fig. 5, for example, the block 5). Further, the service node 50A may obtain the block header information of the block 5 and the mercker path from the structure information 500y to obtain the path hash value in the mercker path. For example, the path Hash value in the merkel path obtained by the service node 50A may be Hash1, Hash12, Hash3, Hash 4.

Meanwhile, the service node 50A may perform transaction hash conversion on the first key transaction data (e.g., the transaction data 41e, the transaction data 43e, and the transaction data 44 e), obtain a key transaction hash value corresponding to the first key transaction data, and determine the tree root to be compared in the block 5. At this time, the service node 50A may obtain the verification result of the block 5 based on the mercker tree root and the tree root to be compared in the block header information.

It is understood that if the verification result indicates that the mercker tree root is consistent with the tree root to be compared, the service node may consider that the verification result indicates that the verification is successful. At this point, the service node 50A may obtain predicted transaction data (e.g., transaction data 52) from the configuration information 500 y. It should be understood that the service node 50A may synchronize the transaction data 41e, the transaction data 43e, the transaction data 44e, the transaction data 52 and the tile header information to the local block chain of the service node 50A, in other words, the service node 50A may take the tile header information of tile 5 as the next tile header of the tile header 4. Upon completion of the block synchronization, transaction data 41e, transaction data 43e, and transaction data 44e may be deleted in node cache 400 of fig. 4 at business node 50A to implement data liquidation.

In this embodiment, when performing block synchronization, a first service node in a service network may send a block synchronization request to a consensus node in a core consensus network through a proxy node for performing network isolation between the core consensus network and the service network, so that the consensus node determines structure information of a dense block corresponding to a block to be synchronized. It can be understood that, when the first service node performs block synchronization, it is not necessary to receive the block to be synchronized including all transaction data, but receive the structure information of the compact block corresponding to the block to be synchronized, like a conventional block chain deployment manner. Further, the first service node may obtain a target transaction identifier representing the initial transaction data from the structure information instead of the complete initial transaction data. The initial transaction data refers to transaction data generated by the first service node when executing transaction service. At this time, the first service node may determine a local transaction identifier corresponding to the first local transaction data in the first node cache, so as to query the first node cache for the transaction data corresponding to the target transaction identifier, so as to reduce data traffic during data transmission. It is to be understood that the first service node may perform block synchronization on the to-be-synchronized block based on the local transaction identifier and the target transaction identifier, and may perform data sorting on the first local transaction data when the block synchronization is completed. Since the first node cache in the embodiment of the present application may store transaction data (for example, initial transaction data) generated by the first service node, when the first service node performs block synchronization, it is not necessary to synchronize complete transaction data from the core consensus network again, and thus repeated transmission of the transaction data between the core consensus network and the service network may be effectively reduced.

Further, please refer to fig. 7, and fig. 7 is a flowchart illustrating a transaction data processing method according to an embodiment of the present application. As shown in fig. 7, the method may be performed by a first service node in the service network, a second service node, a proxy node, and a consensus node in the core consensus network. The first service node may be any one of the nodes in the service network shown in fig. 1, e.g., node 110 a. The second service node may be a node belonging to the same service organization as the first service node, e.g., the second service node may be the node 110b in the service network shown in fig. 1 described above. The proxy node may be the proxy node 10 shown in figure 1 above. The consensus node may be any one of the nodes in the core consensus network shown in fig. 1, described above, e.g., node 120 a. The method may comprise at least the following steps S201-S209:

step S201, sending a block synchronization request to a consensus node belonging to a core consensus network through a proxy node;

step S202, when receiving the structure information forwarded by the consensus node through the agent node, acquiring a target transaction identifier in the structure information;

step S203, determining a local transaction identifier corresponding to the first local transaction data in the first node cache, and comparing the target transaction identifier with the local transaction identifier to obtain a comparison result;

step S204, when the comparison result indicates that the local transaction identifier is the same as the target transaction identifier, taking the local transaction data corresponding to the local transaction identifier in the first node cache as the first key transaction data for verifying the block to be synchronized, performing block synchronization on the block to be synchronized based on the first key transaction data and the structure information, and deleting the first local transaction data in the first node cache when the block synchronization is completed.

For specific implementation of steps S201 to S204, reference may be made to the description of steps S101 to S103 in the embodiment corresponding to fig. 3, which will not be described herein again.

Step S205, when the comparison result indicates that the local transaction identifier is different from the target transaction identifier, the first service node sends a transaction data acquisition request carrying the target transaction identifier to the second service node.

Specifically, when the comparison result indicates that the local transaction identifier is different from the target transaction identifier, the first service node generates a transaction data acquisition request based on the target transaction identifier. Further, the first service node may determine, in the maintained same service organization list, a second service node belonging to the same service organization as the first service node, and may further send the transaction data acquisition request to the second service node.

It will be appreciated that a first service node in a service network may be configured with a list of identical service entities. In this way, when the first service node does not find the local transaction data associated with the target transaction identifier in the first node cache, the first service node can direct the priority query inside the subnet (for example, inside the group service subnet) formed by the same service organization, and further, the bandwidth consumption of the public network of the blockchain service and the access consumption of the consensus node can be reduced. In the embodiment of the present application, service nodes corresponding to node identifiers in the same service organization list may be collectively referred to as a second service node.

The first service node and the second service node may be two different terminal devices logged in by the same account. For example, for a certain individual user, the account corresponding to the individual user may be account a, and the individual user may log in on the first service node by using account a, or may log in on the second service node by using account a. Optionally, the first service node and the second service node may be terminal devices that log in respectively for different accounts owned by the same user. For example, for an enterprise user, the enterprise user may have two different accounts (e.g., account B)₁And account B₂). The first service node may be account B corresponding to the enterprise user₁The logged-in terminal device and the second service node may be account B corresponding to the enterprise user₂The logged-in terminal device.

Step S206, receiving the data query result returned by the second service node.

Specifically, when receiving the transaction data acquisition request, the second service node may obtain a data query result associated with the target transaction identifier in a local cache of the second service node (i.e., a second node cache), and further may send the data query result to the first service node.

It can be understood that the second service node may determine a local transaction identifier corresponding to the second local transaction data in the second node cache, and may further search, in the local transaction identifier corresponding to the second local transaction data, a transaction identifier that is the same as the target transaction identifier carried in the transaction data request, so as to obtain a data query result.

For a specific implementation manner of the second service node searching the local transaction data corresponding to the target transaction identifier in the second node cache, refer to the specific implementation manner of the first service node determining the first key transaction data in the first node cache in the embodiment corresponding to fig. 3, which is not described again here.

Step S207, if the data query result indicates that the second local transaction data corresponding to the target transaction identifier exists in the second node cache, the second local transaction data is used as the second key transaction data for verifying the to-be-synchronized block.

Specifically, if the data query result indicates that the second local transaction data corresponding to the target transaction identifier exists in the second node cache, the first service node may use the second local transaction data as the second key transaction data for verifying the to-be-synchronized block.

It should be understood that, when determining the second key transaction data, the first service node may perform block synchronization on the block to be synchronized based on the second key transaction data and the structure information of the compact block corresponding to the block to be synchronized. For a specific implementation of the block synchronization, reference may be made to the specific implementation of the block synchronization performed on the block to be synchronized by the first service node based on the first critical transaction data and the structure information in the embodiment corresponding to fig. 3, which is not described herein again.

It is to be appreciated that upon completion of the block synchronization, the first service node may generate a data credit notification based on the second critical transaction data, which may in turn be sent to the second service node so that the second service node may delete the second critical transaction data in the second node cache.

For easy understanding, please refer to fig. 8, and fig. 8 is a schematic view of a scenario for receiving a data query result according to a real-time embodiment of the present application. As shown in fig. 8, a service node 81A in this embodiment may be a first service node, the service node 81A may be any one of the service nodes in the service network shown in fig. 1, for example, a node 110a, a service node 82A in this embodiment may be a second service node belonging to the same service organization as the service node 81A, and the service node 82A may be a node 110b in the service network shown in fig. 1.

As shown in fig. 8, the target transaction identifier obtained by the service node 81A from the configuration information in the embodiment of the present application may be the transaction identifier 83 f. Further, the service node 81A may determine a local transaction identifier corresponding to the first local transaction data in a first node cache (e.g., node cache 810) of the service node 81A. For example, the first local transaction data in the node cache 810 may include transaction data 81 and transaction data 82. The transaction identifier corresponding to the transaction data 81 may be a transaction identifier 81f, and the transaction identifier corresponding to the transaction data 82 may be a transaction identifier 82 f.

It is understood that the service node 81A may compare the local transaction identifier with the target transaction identifier (e.g., transaction identifier 83 f) to obtain a comparison result. The comparison result may indicate that the local transaction identifier is different from the target transaction identifier, and at this time, the service node 81A may generate a transaction data obtaining request based on the transaction identifier 83f, and may further send the transaction data obtaining request to the service node 82A.

When the transaction data acquisition request is received by the service node 82A, the service node 82A may determine a local transaction identifier corresponding to second local transaction data in a second node cache (e.g., the node cache 820 shown in fig. 8) to obtain a data query result associated with the target transaction identifier. Further, the service node 82A may return the data query result to the service node 81A.

Since the transaction identifier corresponding to the transaction data 83 determined by the service node 82A is the transaction identifier 83f, the data query result may indicate that the second local transaction data corresponding to the transaction identifier 83f, i.e., the transaction data 83, exists in the node cache 820. At this time, the service node 81A may use the transaction data 83 as second critical transaction data, and further may synchronize the to-be-synchronized blocks based on the transaction data 83 and the structure information, and when the block synchronization is completed, may generate a data clearing notification sent to the service node 82A based on the transaction data 83, so that the service node 82A may delete the transaction data 83 in the node cache 820.

Step S208, if the data query result indicates that the second local transaction data corresponding to the target transaction identifier does not exist in the second node cache, the transaction data acquisition request is sent to the consensus node through the proxy node, so that the consensus node acquires the target transaction data corresponding to the target transaction identifier in the to-be-synchronized block, and sends the target transaction data to the proxy node.

Specifically, if the data query result indicates that the second local transaction data corresponding to the target transaction identifier does not exist in the second node cache, it may be considered that the first service node fails to acquire the transaction data corresponding to the target transaction identifier from the second service node included in the same service organization list. At this time, the first service node may send the transaction data acquisition request to the proxy node, so that the proxy node sends the transaction data acquisition request to the consensus node in the core consensus network. When receiving the transaction data acquisition request, the consensus node may acquire target transaction data corresponding to the target transaction identifier in the block to be synchronized, and send the target transaction data to the agent node.

Step S209, receiving the target transaction data forwarded by the consensus node through the proxy node, using the target transaction data as third key transaction data for verifying the block to be synchronized, and synchronizing the block to be synchronized based on the third key transaction data and the structure information.

Specifically, the first service node may receive target transaction data forwarded by the consensus node through the proxy node, and may further use the target transaction data as third key transaction data for verifying the to-be-synchronized block. Further, the first service node may synchronize the to-be-synchronized block based on the third critical transaction data and the structure information.

For the specific implementation manner of the first service node performing block synchronization on the block to be synchronized based on the third critical transaction data and the structure information, reference may be made to the specific implementation manner of the first service node performing block synchronization on the block to be synchronized based on the first critical transaction data and the structure information in the embodiment corresponding to fig. 3, which is not described herein again.

For example, the target transaction identifier acquired by the service node 81A shown in fig. 8 is the transaction identifier 84f, and then the transaction data acquisition request generated by the service node 81A may carry the transaction identifier 84 f. At this point, the service node 82A may obtain the data query result associated with the transaction identifier 84f based on the transaction data acquisition request. Wherein the data query result may indicate that the second local transaction data corresponding to the transaction identifier 84f does not exist in the node cache 820.

It will be appreciated that the same service organization list maintained by service node 81A may also include a node identification of another second service node (e.g., service node 83A). Wherein the transaction data 84 is stored in a node cache (e.g., node cache 830) of the service node 83A. However, the service node 83A may be disconnected due to equipment failure or network outage, so that the service node 81A cannot acquire the transaction data 84 in the service node 83A. At this time, the service node 81A may send a transaction data obtaining request carrying the transaction identifier 84f to a consensus node in the core consensus network through the proxy node.

When receiving the transaction data acquisition request, the consensus node may acquire target transaction data (e.g., transaction data 84) corresponding to the transaction identifier 84f in the to-be-synchronized block, and may further send the transaction data 84 to the agent node, so that the agent node may forward the transaction data 84 to the service node 81A. It should be understood that when the transaction data 84 is received by the service node 81A, the transaction data 84 can be used as the third key transaction data for verifying the block to be synchronized, and the block to be synchronized can be synchronized based on the transaction data 84 and the structure information.

For ease of understanding, please refer to fig. 9, and fig. 9 is a system architecture diagram in a context of a blockchain electronic ticket according to an embodiment of the present application. As shown in fig. 9, the service layer, the routing agent layer and the core consensus network layer in the embodiment of the present application constitute a whole complete blockchain service system. Core chain 1, core chain 2, …, and core chain N shown in FIG. 9 are each a target blockchain maintained by a tax bureau in a different area. For example, the transaction service in the embodiment of the present application may take an electronic bill transfer service as an example, which is not limited herein.

It is understood that when the blockchain is used in some scenarios of government (e.g., tax system) or commercial institutions, in order to improve the confidentiality and security of data, related data such as personal privacy or national security are involved in the blockchain system, a hierarchical blockchain structure of "service network-core consensus network" in the embodiments of the present application may be used.

The service layer is in the witness network, and the service node (e.g., the first service node) in the service layer may include a terminal device corresponding to an electronic tax bureau, a terminal device corresponding to an enterprise user, and a terminal device corresponding to a consuming user. The electronic tax office may refer to a local tax office in a private network of the tax office, the enterprise user may be an invoicing facilitator, an reimbursement facilitator, or a retail enterprise (e.g., KA enterprise, i.e., large retail customer and key retail customer enterprise) in a public cloud, and the consumer user may be a payment facilitator, a circulation facilitator, or a retail enterprise in a private cloud. For example, the ticket transfer service executed by the first service node (e.g., the terminal device a corresponding to the consuming user) may be: and transferring the electronic bill (for example, the electronic bill X) obtained when the consumer purchases the equipment to the corresponding terminal device B of the enterprise where the consumer is located. Of course, a second service node belonging to the same service organization as the first service node may be included in the service layer. For example, two invoicers (e.g., employee 1 and employee 2) of a company, issuing invoices on respective terminal devices, produces some transaction data. For example, employee 1 may perform a transaction using terminal device a1 to generate transaction data, and employee 2 may perform a transaction using terminal device a2 to generate corresponding transaction data. Since the address of the transaction is the address of the company, the transaction data generated at terminal a1 and the transaction data generated at terminal a1 belong to the company. Except that the transaction data is stored in a local cache (i.e., node cache) in a different terminal device. At this time, terminal device a1 used by employee 1 may be referred to as a first service node, and terminal device a2 used by employee 2 may be referred to as a second service node belonging to the same service organization as the first service node. The transaction data generated by the first service node is stored in the first node cache, and the transaction data generated by the second service node is stored in the second node cache.

The proxy node in the routing proxy layer may be used for network isolation between the service layer and the core consensus network layer, and the proxy node may have a point-to-point service (i.e., P2P service), a routing service, a certificate cache, and an authentication service. It is understood that the point-to-point service refers to a service in the P2P network, and based on a specific network protocol, a central node is not required between network nodes in the P2P network to maintain the network state, but each node maintains the node state of the whole network or the connection state of its neighboring nodes through broadcast interaction with the neighboring nodes. Routing services are basic functions that nodes have and may be used for communication between nodes. The certificate in the certificate cache may refer to Public Key Infrastructure (PKI), in which the certificate is an identification of a Public Key owner and is issued by an authority (CA). Asymmetric encryption and digital signature of information can be realized based on a public key certificate system. The public key certificate system herein may include a public-private key password, an x509 certificate, a CA certificate issuing center, and the like. The authentication service may be used to verify transaction format, node legitimacy, etc. of the received information (e.g., initial transaction data sent by the service node). It can be understood that, in the embodiment of the present application, the proxy node may forward, to the first node in the service layer, structure information of a dense block corresponding to a block to be synchronized, which is sent by a consensus node in the core consensus network layer. In the forwarding process, the agent node can sign the structure information to obtain signature information, and encrypt the structure information and the signature information to obtain system encrypted data information to be sent to a service layer.

Wherein, the consensus node (i.e. the accounting node) in the core consensus network layer may be a trusted node in the tax private network. It will be appreciated that each consensus node has the ability to wrap out a block, i.e., the initial transaction data forwarded by the proxy node can be verified and added to the transaction pool (i.e., the cache shown in fig. 9) of the consensus node when the verification is successful. Further, the consensus node may pack out a block of transaction data in its own transaction pool, so as to successfully write the block into a target block chain in the core consensus network layer. In addition, when receiving the block synchronization request forwarded by the proxy node, the consensus node may determine predicted transaction data in the block to be synchronized by invoking an authority contract (e.g., an intelligent contract) to generate structural information of the dense block corresponding to the block to be synchronized.

In this embodiment of the present application, in a layered structure such as a "service network-core consensus network", when a first service node in a service network performs block synchronization, a proxy node for performing network isolation between the core consensus network and the service network may send a block synchronization request to a consensus node in the core consensus network, so that the consensus node determines structure information of a dense block corresponding to a block to be synchronized. It can be understood that, when the first service node performs block synchronization, it is not necessary to receive the block to be synchronized including all transaction data, but receive the structure information of the compact block corresponding to the block to be synchronized, like a conventional block chain deployment manner. The structure information comprises lightweight block header information and a target transaction identifier used for representing initial transaction data, but not complete initial transaction data, so that unnecessary network flow is greatly reduced, and high-performance operation of the core consensus network can be guaranteed. Further, after the first service node acquires the target transaction identifier from the structure information, it may further determine a local transaction identifier corresponding to the first local transaction data in the first node cache, so as to query the transaction data corresponding to the target transaction identifier in the first node cache. It is to be appreciated that the first service node can block synchronize the block to be synchronized based on the local transaction identifier and the target transaction identifier, and upon completion of the block synchronization, can data-liquidate the first local transaction data. Therefore, the initial transaction data in the embodiment of the present application may be generally cached in a local cache (i.e., a first node cache) or in a group service subnet (i.e., in a subnet formed by service nodes belonging to the same service organization), so that when the first service node performs block synchronization, it is not necessary to synchronize complete transaction data from the core consensus network again, and thus, the repeated transmission of the transaction data between the core consensus network and the service network may be effectively reduced.

Further, please refer to fig. 10, where fig. 10 is a schematic structural diagram of a transaction data processing apparatus according to an embodiment of the present application. As shown in fig. 10, the transaction data processing device 1 may be a computer program (including program code) running in a computer apparatus, for example, the transaction data processing device 1 is an application software; the transaction data processing device 1 may be used to perform corresponding steps in the method provided by the embodiments of the present application. As shown in fig. 10, the transaction data processing device 1 may operate in a first service node in a service network, and the first service node may be the service node 20A in the embodiment corresponding to fig. 2. The transaction data processing device 1 may include: the system comprises a block synchronization request sending module 11, a target identifier obtaining module 12, a data sorting module 13, an initial transaction determining module 14, an initial transaction adding module 15, a target transaction set determining module 16, a cochain result receiving module 17, an initial transaction deleting module 18, a first sending module 19, a data query result receiving module 20, a first determining module 21, a sorting notification generating module 22, a sorting notification sending module 23, a second sending module 24, a second determining module 25 and a block synchronization module 26.

The block synchronization request sending module 11 is configured to send a block synchronization request to a consensus node belonging to a core consensus network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the service network is a network where a first service node requesting to send a block synchronization request is located; the block synchronization request is used for indicating the consensus node to generate the structure information of the compact block corresponding to the block to be synchronized; the structure information includes a target transaction identifier; the target transaction identifier is determined by the consensus node after performing hash identity conversion on the initial transaction data.

The first service node is a light weight node;

the block synchronization request sending module 11 includes: a block synchronization request generating unit 111 and a block synchronization request transmitting unit 112.

The block synchronization request generating unit 111 is configured to obtain a block hash value corresponding to a block header having a largest block generation timestamp from a local block chain of the first service node, and generate a block synchronization request for instructing a consensus node in the core consensus network to perform block synchronization based on the block hash value;

the block synchronization request sending unit 112 is configured to obtain node identification information of the first service node, and send the node identification information and the block synchronization request to the proxy node, so that the proxy node forwards the block synchronization request to the common node according to the legal verification result; the legal verification result is obtained when the agent node does not find the illegal node identification which is the same as the node identification information in the illegal node list.

For specific implementation of the block synchronization request generating unit 111 and the block synchronization request sending unit 112, reference may be made to the description of step S101 in the embodiment corresponding to fig. 3, and details will not be further described here.

The target identifier acquisition module 12 is configured to, when receiving the structural information forwarded by the consensus node through the agent node, acquire a target transaction identifier in the structural information;

the target identifier obtaining module 12 includes: an encrypted information acquisition unit 121, a decryption processing unit 122, a signature verification unit 123, and a target identifier acquisition unit 124.

The encrypted information obtaining unit 121 is configured to obtain system encrypted data information sent by the proxy node; the system encryption data information is obtained by the proxy node through encrypting the structure information and the signature information through a system public key of the service network; the signature information is obtained after the agent node signs the structural information through a node private key of the agent node when the agent node obtains the structural information sent by the consensus node;

the decryption processing unit 122 is configured to decrypt the system encrypted data information through a system private key corresponding to the system public key to obtain structure information and signature information;

the signature verification unit 123 is configured to obtain a node public key of the agent node, and verify the signature of the signature information based on the node public key to obtain a signature verification result;

the target identifier obtaining unit 124 is configured to obtain the target transaction identifier corresponding to the initial transaction data from the structure information when the signature verification result indicates that the signature verification is successful.

For specific implementation manners of the encrypted information obtaining unit 121, the decryption processing unit 122, the signature verification unit 123 and the target identifier obtaining unit 124, reference may be made to the description of step S102 in the embodiment corresponding to fig. 3, and details will not be further described here.

The data sorting module 13 is configured to determine a local transaction identifier corresponding to first local transaction data in the first node cache, perform block synchronization on a block to be synchronized based on the target transaction identifier and the local transaction identifier, and perform data sorting on the first local transaction data when the block synchronization is completed.

The target transaction identifier is determined by the consensus node after performing hash identification conversion on the initial transaction data based on an identifier determination rule;

the data sorting module 13 includes: an identifier conversion unit 131, an identifier comparison unit 132, a transaction determination unit 133 and a deletion unit 134.

The identifier conversion unit 131 is configured to obtain an identifier determination rule, and perform hash identifier conversion on first local transaction data in a first node cache of a first service node based on the identifier determination rule to obtain a local transaction identifier corresponding to the first local transaction data;

the identification converting unit 131 includes: a first hash conversion sub-unit 1311 and a second hash conversion sub-unit 1312.

The first hash conversion subunit 1311 is configured to perform, based on a first hash rule in the identifier determination rule, first hash conversion on first local transaction data in a first node cache of the first service node, to obtain a first hash value corresponding to the first local transaction data;

the second hash conversion sub-unit 1312 is configured to perform a second hash conversion on the first hash value based on a second hash rule to obtain a second hash value corresponding to the first local transaction data, and obtain a local transaction identifier corresponding to the first local transaction data based on the second hash value and the number of hash bytes associated with the second hash rule.

For a specific implementation manner of the first hash conversion sub-unit 1311 and the second hash conversion sub-unit 1312, reference may be made to the description of the local transaction identifier corresponding to the first local transaction data in the embodiment corresponding to fig. 3, and details will not be further described here.

The identifier comparing unit 132 is configured to compare the local transaction identifier with the target transaction identifier to obtain a comparison result;

the transaction determining unit 133 is configured to, when the comparison result indicates that the local transaction identifier is the same as the target transaction identifier, take the local transaction data corresponding to the local transaction identifier in the first node cache as the first key transaction data for verifying the to-be-synchronized block;

the deleting unit 134 is configured to perform block synchronization on a block to be synchronized based on the first key transaction data and the structure information, and delete the first local transaction data in the first node cache when the block synchronization is completed.

Wherein the deleting unit 134 includes: an acquisition subunit 1341, a to-be-compared tree root determination subunit 1342, a verification result determination subunit 1343, and a deletion subunit 1344.

The obtaining subunit 1341 is configured to obtain block header information of a block to be synchronized and a mercker path from the structure information;

the to-be-compared tree root determining subunit 1342 is configured to obtain a key transaction hash value corresponding to the first key transaction data and a path hash value in the mercker path, and determine a to-be-compared tree root of the to-be-synchronized block;

the verification result determining subunit 1343 is configured to obtain a verification result of the block to be synchronized based on the mercker tree root in the block header information and the tree root to be compared;

the delete subunit 1344 is configured to, if the verification result indicates that the verification is successful, perform block synchronization on the to-be-synchronized block, and delete the first local transaction data in the first node cache when the block synchronization is completed.

Wherein the delete subunit 1344 is further configured to:

the first critical transaction data, the predicted transaction data, and the block header information are synchronized to a local blockchain of the first service node.

For specific implementation manners of the acquiring subunit 1341, the to-be-compared tree root determining subunit 1342, the verification result determining subunit 1343, and the deleting subunit 1344, reference may be made to the description of performing data sorting on the first local transaction data in the first node cache in the embodiment corresponding to fig. 3, which will not be further described herein.

For specific implementation manners of the identifier converting unit 131, the identifier comparing unit 132, the transaction determining unit 133 and the deleting unit 134, reference may be made to the description of step S103 in the embodiment corresponding to fig. 3, and details will not be further described here.

The initial transaction determining module 14 is configured to obtain a transaction service request sent by a user terminal, execute a transaction service requested by the user terminal based on the transaction service request, and obtain initial transaction data according to a transaction execution result of the transaction service;

the initial transaction adding module 15 is configured to send initial transaction data to the consensus node through the proxy node based on the dense block connection mode, and add the initial transaction data to the initial transaction data set corresponding to the first node cache; the dense block connection mode is used for instructing the consensus node to take the target block as the block to be synchronized and generate the structural information of the dense block corresponding to the block to be synchronized when the target block containing the initial transaction data is written into the target block chain of the core consensus network.

The target transaction set determining module 16 is configured to obtain a target transaction data set corresponding to the first node cache when the initial transaction data is added to the initial transaction data set corresponding to the first node cache;

the uplink result receiving module 17 is configured to receive an uplink failure result forwarded by the consensus node through the proxy node when the consensus node fails to write the target block including the initial transaction data into the target block chain of the core consensus network;

the initial transaction deletion module 18 is configured to delete the initial transaction data in the target transaction data set corresponding to the first node cache based on the uplink failure result.

the first sending module 19 is configured to send, to the second service node, a transaction data acquisition request carrying the target transaction identifier when the comparison result indicates that the local transaction identifier is different from the target transaction identifier; the transaction data acquisition request is used for indicating the second service node to obtain a data query result associated with the target transaction identifier in second local transaction data in a second node cache;

the data query result receiving module 20 is configured to receive a data query result returned by the second service node;

the first determining module 21 is configured to, if the data query result indicates that second local transaction data corresponding to the target transaction identifier exists in the second node cache, use the second local transaction data as second key transaction data for verifying the to-be-synchronized block.

The clearing notification generating module 22 is configured to perform block synchronization on a block to be synchronized based on the second key transaction data and the structural information, and generate a data clearing notification based on the second key transaction data when the block synchronization is completed;

the score clearing notification sending module 23 is configured to send a data score clearing notification to the second service node, so that the second service node deletes the second key transaction data in the second node cache.

The second sending module 24 is configured to send, by the proxy node, the transaction data acquisition request to the consensus node if the data query result indicates that the second local transaction data corresponding to the target transaction identifier does not exist in the second node cache; the transaction data acquisition request is used for indicating the consensus node to be in the block to be synchronized, acquiring target transaction data corresponding to the target transaction identifier, and sending the target transaction data to the agent node;

the second determining module 25 is configured to receive target transaction data forwarded by the consensus node through the proxy node, and use the target transaction data as third key transaction data for verifying the block to be synchronized;

the block synchronization module 26 is configured to perform block synchronization on the block to be synchronized based on the third critical transaction data and the structure information.

For specific implementation manners of the block synchronization request sending module 11, the target identifier obtaining module 12, the data sorting module 13, the initial transaction determining module 14, the initial transaction adding module 15, the target transaction set determining module 16, the uplink result receiving module 17, the initial transaction deleting module 18, the first sending module 19, the data query result receiving module 20, the first determining module 21, the sorting notification generating module 22, the sorting notification sending module 23, the second sending module 24, the second determining module 25, and the block synchronization module 26, reference may be made to the description of step S201 to step S209 in the embodiment corresponding to fig. 7, and further description will not be repeated here. In addition, the beneficial effects of the same method are not described in detail.

Further, please refer to fig. 11, where fig. 11 is a schematic diagram of a computer device according to an embodiment of the present application. As shown in fig. 11, the computer device 1000 may be a first service node in a service network, and the first service node may be the service node 20A in the embodiment corresponding to fig. 2, and the computer device 1000 may include: at least one processor 1001, such as a CPU, at least one network interface 1004, a user interface 1003, memory 1005, at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display (Display) and a Keyboard (Keyboard), and the network interface 1004 may optionally include a standard wired interface and a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may optionally also be at least one storage device located remotely from the aforementioned processor 1001. As shown in fig. 11, a memory 1005, which is a kind of computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

In the computer device 1000 shown in fig. 11, the network interface 1004 is mainly used for network communication with the proxy node, the second service node; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

sending a block synchronization request to a consensus node belonging to a core consensus network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the service network is a network where a first service node requesting to send a block synchronization request is located; the block synchronization request is used for indicating the consensus node to generate the structure information of the compact block corresponding to the block to be synchronized; the structure information includes a target transaction identifier; the target transaction identifier is determined by the consensus node after the initial transaction data is subjected to hash identification conversion;

and determining a local transaction identifier corresponding to the first local transaction data in the first node cache, performing block synchronization on the block to be synchronized based on the target transaction identifier and the local transaction identifier, and performing data sorting on the first local transaction data when the block synchronization is completed.

It should be understood that the computer device 1000 described in this embodiment of the present application may perform the description of the transaction data processing method in the embodiment corresponding to fig. 3 and fig. 7, and may also perform the description of the transaction data processing apparatus 1 in the embodiment corresponding to fig. 10, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored, where the computer program includes program instructions, and when the program instructions are executed by a processor, the data transmission method provided in each step in fig. 3 and fig. 7 is implemented, which may specifically refer to the implementation manner provided in each step in fig. 3 and fig. 7, and is not described herein again.

The computer readable storage medium may be the data transmission device provided in any of the foregoing embodiments or an internal storage unit of the computer device, such as a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Memory Card (SMC), a Secure Digital (SD) card, a flash card (flash card), and the like, provided on the computer device. Further, the computer-readable storage medium may also include both an internal storage unit and an external storage device of the computer device. The computer-readable storage medium is used for storing the computer program and other programs and data required by the computer device. The computer readable storage medium may also be used to temporarily store data that has been output or is to be output.

An aspect of the application provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and executes the computer instruction, so that the computer device can execute the description of the transaction data processing method in the embodiment corresponding to fig. 3 or fig. 7, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

The terms "first," "second," and the like in the description and in the claims and drawings of the embodiments of the present application are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "comprises" and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, product, or apparatus that comprises a list of steps or elements is not limited to the listed steps or modules, but may alternatively include other steps or modules not listed, or may alternatively include other steps or elements inherent to such process, method, apparatus, product, or apparatus.

Those of ordinary skill in the art will appreciate that the various illustrative components and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the components and steps of the various examples have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the technical solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The method and the related apparatus provided by the embodiments of the present application are described with reference to the flowchart and/or the structural diagram of the method provided by the embodiments of the present application, and each flow and/or block of the flowchart and/or the structural diagram of the method, and the combination of the flow and/or block in the flowchart and/or the block diagram can be specifically implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable transaction data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable transaction data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable transaction data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be loaded onto a computer or other programmable transaction data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block or blocks.

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

Claims

1. A method of transaction data processing, comprising:

sending a block synchronization request to a consensus node belonging to a core consensus network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the service network is a network where a first service node requesting to send the block synchronization request is located; the block synchronization request is used for indicating the consensus node to generate structure information of a compact block corresponding to a block to be synchronized; the structural information includes a target transaction identifier; the target transaction identifier is determined by the consensus node after performing hash identification conversion on initial transaction data; the initial transaction data is generated by the first service node when executing transaction service, and the initial transaction data belongs to the block to be synchronized;

when the first service node receives the structural information forwarded by the consensus node through the agent node, acquiring a target transaction identifier in the structural information;

the first service node determines a local transaction identifier corresponding to first local transaction data in a first node cache, performs block synchronization on the block to be synchronized based on a comparison result of the target transaction identifier and the local transaction identifier, and performs data clearing on the first local transaction data when the block synchronization is completed; the first local transaction data is local transaction data included by the first node cache before data clearing; the first node cache is a node cache of the first service node.

2. The method of claim 1, further comprising:

acquiring a transaction service request sent by a user terminal, executing the transaction service requested by the user terminal based on the transaction service request, and obtaining the initial transaction data according to a transaction execution result of the transaction service;

sending the initial transaction data to the consensus node through the agent node based on a dense block connection mode, and adding the initial transaction data to a first node cache corresponding initial transaction data set; and the compact block connection mode is used for indicating the consensus node to take the target block containing the initial transaction data as a block to be synchronized and generate structure information of a compact block corresponding to the block to be synchronized when the target block is written into a target block chain of the core consensus network.

3. The method of claim 2, further comprising:

when the initial transaction data is added to the initial transaction data set corresponding to the first node cache, obtaining a target transaction data set corresponding to the first node cache;

receiving a uplink failure result forwarded by the consensus node through the proxy node when the consensus node fails to write a target block containing the initial transaction data into a target block chain of the core consensus network;

deleting the initial transaction data in the target transaction data set corresponding to the first node cache based on the uplink failure result.

4. The method of claim 1, wherein the first traffic node is a lightweight node;

the sending of the block synchronization request to the consensus node belonging to the core consensus network by the proxy node comprises:

acquiring a block hash value corresponding to a block head with a maximum block generation timestamp from a local block chain of the first service node, and generating a block synchronization request for instructing a consensus node in a core consensus network to perform block synchronization based on the block hash value;

acquiring node identification information of the first service node, and sending the node identification information and the block synchronization request to a proxy node so that the proxy node forwards the block synchronization request to the consensus node according to a legal verification result; the legal verification result is obtained when the proxy node does not find the illegal node identification which is the same as the node identification information in the illegal node list.

5. The method of claim 1, wherein the first service node, upon receiving the structure information forwarded by the consensus node through the proxy node, obtains a target transaction identifier in the structure information, and comprises:

the first service node acquires system encryption data information sent by the agent node; the system encryption data information is obtained after the agent node encrypts the structure information and the signature information through a system public key of the service network; the signature information is obtained after the agent node signs the structural information through a node private key of the agent node when the agent node obtains the structural information sent by the consensus node;

decrypting the system encrypted data information through a system private key corresponding to the system public key to obtain the structure information and the signature information;

acquiring a node public key of the agent node, and checking the signature of the signature information based on the node public key to obtain a signature checking result;

and when the signature verification result indicates that signature verification is successful, acquiring a target transaction identifier corresponding to the initial transaction data from the structural information.

6. The method of claim 1, wherein the target transaction identifier is determined by the consensus node after a hash identification transformation of the initial transaction data based on an identifier determination rule;

the first service node determining a local transaction identifier corresponding to first local transaction data in a first node cache, performing block synchronization on the block to be synchronized based on a comparison result of the target transaction identifier and the local transaction identifier, and performing data sorting on the first local transaction data when the block synchronization is completed, includes:

the first service node acquires the identifier determining rule, and performs hash identification conversion on first local transaction data in a first node cache of the first service node based on the identifier determining rule to obtain a local transaction identifier corresponding to the first local transaction data;

comparing the local transaction identifier with the target transaction identifier to obtain a comparison result;

when the comparison result indicates that the local transaction identifier is the same as the target transaction identifier, taking local transaction data corresponding to the local transaction identifier in the first node cache as first key transaction data for verifying the to-be-synchronized block;

and performing block synchronization on the block to be synchronized based on the first key transaction data and the structural information, and deleting the first local transaction data in the first node cache when the block synchronization is completed.

7. The method of claim 6, wherein the identifier determination rule comprises: a first hash rule and a second hash rule; the first hash rule is different from the second hash rule;

the obtaining, by the first service node, the identifier determination rule, and performing hash identifier conversion on first local transaction data in a first node cache of the first service node based on the identifier determination rule to obtain a local transaction identifier corresponding to the first local transaction data includes:

the first service node performs first hash conversion on first local transaction data in a first node cache of the first service node based on the first hash rule in the identifier determination rule to obtain a first hash value corresponding to the first local transaction data;

and performing second hash conversion on the first hash value based on the second hash rule to obtain a second hash value corresponding to the first local transaction data, and obtaining a local transaction identifier corresponding to the first local transaction data based on the second hash value and the hash byte number associated with the second hash rule.

8. The method of claim 6, wherein block synchronizing the block to be synchronized based on the first critical transaction data and the structure information, and deleting the first local transaction data in the first node cache upon completion of block synchronization, comprises:

acquiring block header information and a Mercker path of the block to be synchronized from the structure information;

acquiring a key transaction hash value corresponding to the first key transaction data and a path hash value in the Mercker path, and determining a tree root to be compared of the block to be synchronized;

obtaining a verification result of the block to be synchronized based on the Mercker tree root in the block header information and the tree root to be compared;

and if the verification result indicates that the verification is successful, block synchronization is carried out on the block to be synchronized, and when the block synchronization is completed, the first local transaction data is deleted in the first node cache.

9. The method of claim 8, wherein block synchronizing the to-be-synchronized block if the verification result indicates successful verification, and deleting the first local transaction data in the first node cache upon completion of block synchronization comprises:

if the verification result indicates that the verification is successful, obtaining predicted transaction data from the structural information; the predicted transaction data is selected by the consensus node from all transaction data in the block to be synchronized based on an intelligent contract and is associated with the first service node;

synchronizing the first critical transaction data, the predicted transaction data, and the block header information to a local blockchain of the first service node.

10. The method of claim 6, wherein the service network includes a second service node, and wherein the second service node is a node in the same service mechanism list maintained by the first service node;

the method further comprises the following steps:

when the comparison result indicates that the local transaction identifier is different from the target transaction identifier, sending a transaction data acquisition request carrying the target transaction identifier to the second service node; the transaction data acquisition request is used for indicating the second service node to obtain a data query result associated with the target transaction identifier in second local transaction data in a second node cache;

receiving the data query result returned by the second service node;

and if the data query result indicates that second local transaction data corresponding to the target transaction identifier exists in the second node cache, taking the second local transaction data as second key transaction data for verifying the to-be-synchronized block.

11. The method of claim 10, further comprising:

performing block synchronization on the block to be synchronized based on the second key transaction data and the structural information, and generating a data clearing notice based on the second key transaction data when the block synchronization is completed;

and sending the data clearing notice to the second service node so that the second service node deletes the second key transaction data in the second node cache.

12. The method of claim 10, further comprising:

if the data query result indicates that second local transaction data corresponding to the target transaction identifier does not exist in the second node cache, sending the transaction data acquisition request to the consensus node through the proxy node; the transaction data acquisition request is used for indicating the consensus node to acquire target transaction data corresponding to the target transaction identifier in the block to be synchronized and sending the target transaction data to the agent node;

receiving the target transaction data forwarded by the consensus node through the agent node, and taking the target transaction data as third key transaction data for verifying the to-be-synchronized block;

and carrying out block synchronization on the block to be synchronized based on the third key transaction data and the structural information.

13. A transaction data processing apparatus, comprising:

the block synchronization request sending module is used for sending a block synchronization request to the consensus node belonging to the core consensus network through the proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the service network is a network where a first service node requesting to send the block synchronization request is located; the block synchronization request is used for indicating the consensus node to generate structure information of a compact block corresponding to a block to be synchronized; the structural information includes a target transaction identifier; the target transaction identifier is determined by the consensus node after performing hash identification conversion on initial transaction data; the initial transaction data is generated when the first service node executes transaction service, and the initial transaction data belongs to the block to be synchronized;

a target identifier obtaining module, configured to, when the first service node receives the structural information forwarded by the consensus node through the agent node, obtain a target transaction identifier in the structural information;

the data clearing module is used for the first service node to determine a local transaction identifier corresponding to first local transaction data in a first node cache, perform block synchronization on the block to be synchronized based on a comparison result of the target transaction identifier and the local transaction identifier, and perform data clearing on the first local transaction data when the block synchronization is completed; the first local transaction data is local transaction data included by the first node cache before data clearing; the first node cache is a node cache of the first service node.

14. A computer device, comprising: a processor and a memory;

the processor is coupled to a memory, wherein the memory is configured to store a computer program, and the processor is configured to invoke the computer program to cause the computer device to perform the method of any of claims 1-12.

15. A computer-readable storage medium, in which a computer program is stored which is adapted to be loaded and executed by a processor to cause a computer device having said processor to carry out the method of any one of claims 1 to 12.