CN112396423B

CN112396423B - Transaction data processing method, device, equipment and storage medium

Info

Publication number: CN112396423B
Application number: CN202110078262.XA
Authority: CN
Inventors: 朱耿良
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-01-20
Filing date: 2021-01-20
Publication date: 2021-04-13
Anticipated expiration: 2041-01-20
Also published as: CN112396423A; CN112926982A; CN112926982B

Abstract

The embodiment of the application discloses a transaction data processing method, a device, equipment and a storage medium, wherein the method comprises the following steps: the first node acquires initial transaction data forwarded by the proxy node, and packages the initial transaction data to obtain a block to be verified; the initial transaction data is sent by a service node in the service network; the agent node is used for carrying out network isolation on the service network and the core consensus network; acquiring a second node from the core consensus network, and acquiring first structure information of a compact block corresponding to the block to be verified based on the predicted auxiliary information of the second node and the block information of the block to be verified; the first structure information comprises a target transaction identifier corresponding to the initial transaction data; and broadcasting the first structure information to the second node so that the second node can identify the to-be-verified block based on the target transaction identifier. By adopting the embodiment of the application, frequent broadcasting of transaction data can be reduced, so that the overall consensus performance can be improved.

Description

Transaction data processing method, device, equipment and storage medium

Technical Field

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

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 block chain nodes in the block chain network regularly and randomly select to send messages to surrounding nodes, and the nodes receiving the messages repeat the steps. For example, a blockchain node (e.g., node a), upon receiving transaction data (e.g., transaction data x) broadcast by a certain node (e.g., node B), may also broadcast the transaction data x to other nodes (e.g., node C). Based on this, the node a may repeatedly receive the transaction data x broadcasted by other nodes before putting the transaction data x into its own transaction pool. For example, when acquiring the transaction data x broadcast by the node C, the node D also broadcasts the transaction data x to other nodes (e.g., the node a) indiscriminately, so that a frequent broadcast phenomenon of the same transaction data x exists at the node a.

In addition, after receiving the transaction data x, the node C may perform a packing process on the transaction data x and other transaction data together to obtain a to-be-verified block to be written into the blockchain network. At this time, the node C needs to broadcast the complete block to be verified including all the transaction data to all the nodes in the consensus network, so that the consensus node (for example, the node a) in the consensus network still obtains the transaction data x in the block to be verified again without distinction, and further the transaction data x is repeatedly broadcast in the whole consensus network, so that when the transaction data in the block to be verified are consensus, the overall consensus performance is reduced.

Disclosure of Invention

The embodiment of the application provides a transaction data processing method, a transaction data processing device and a transaction data processing storage medium, which can reduce frequent broadcasting of transaction data, and thus can improve the overall consensus performance.

In one aspect, an embodiment of the present application provides a transaction data processing method, where the method is performed by a first node in a core consensus network, and the method includes:

acquiring initial transaction data forwarded by the agent node, and packaging the initial transaction data to obtain a to-be-verified block to be broadcasted to the core consensus network; the initial transaction data is sent by a service node in the service network; the agent node is used for carrying out network isolation on the service network and the core consensus network;

acquiring a second node from the core consensus network, and acquiring first structure information of a compact block corresponding to the block to be verified based on the predicted auxiliary information of the second node and the block information of the block to be verified; the first structure information comprises a target transaction identifier corresponding to the initial transaction data; the target transaction identifier is determined after the initial transaction data is subjected to hash identification conversion;

and broadcasting the first structure information to the second node so that the second node can identify the to-be-verified block based on the target transaction identifier.

In one aspect, an embodiment of the present application provides a transaction data processing method, where the method is performed by a second node in a core consensus network, and the method includes:

receiving first structure information of a compact block corresponding to a block to be verified, which is sent by a first node in a core consensus network; the block to be verified is obtained by packaging the initial transaction data by the first node; the initial transaction data is forwarded by the service node in the service network through the proxy node; the agent node is used for carrying out network isolation on the service network and the core consensus network; the first structure information is determined by the first node based on the predicted prediction auxiliary information of the second node and the block information of the block to be verified;

acquiring a target transaction identifier from the first structure information, and identifying the to-be-verified block based on the target transaction identifier; the target transaction identifier is determined by the first node after hash identification conversion of the initial transaction data.

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

the packaging processing module is used for acquiring initial transaction data forwarded by the agent node, packaging the initial transaction data and obtaining a to-be-verified block to be broadcasted to the core consensus network; the initial transaction data is sent by a service node in the service network; the agent node is used for carrying out network isolation on the service network and the core consensus network;

the structure information determining module is used for acquiring a second node from the core consensus network, and obtaining first structure information of a compact block corresponding to the block to be verified based on the predicted auxiliary information of the second node and the block information of the block to be verified; the first structure information comprises a target transaction identifier corresponding to the initial transaction data; the target transaction identifier is determined after the initial transaction data is subjected to hash identification conversion;

and the structure information broadcasting module is used for broadcasting the first structure information to the second node so that the second node can identify the to-be-verified block based on the target transaction identifier.

Wherein, this packing processing module includes:

the transaction verification unit is used for acquiring initial transaction data forwarded by a service node in a service network through a proxy node, and performing transaction verification on the initial transaction data to obtain a transaction verification result;

the transaction adding unit is used for adding initial transaction data to a first transaction pool of the first node when the transaction verification result indicates that the transaction verification is successful, acquiring a transaction data set containing the initial transaction data from the first transaction pool, and taking the transaction data in the transaction data set as transaction data to be processed;

the transaction hash determining unit is used for performing transaction hash conversion on the transaction data to be processed to obtain a transaction hash value corresponding to the transaction data to be processed, and determining a Merck tree root corresponding to the transaction data to be processed based on the transaction hash value;

a to-be-verified block generation unit, configured to acquire a first block with a maximum generation timestamp from a target block chain of a core consensus network, use a block hash value of the first block as a parent block hash value of a next block of the first block, generate the next block of the first block based on to-be-processed transaction data, a merkel root, and the parent block hash value, and use the generated next block of the first block as a to-be-verified block to be written into the target block chain; the generation timestamp of the to-be-verified block is used to update the maximum generation timestamp on the target blockchain.

Wherein the transaction verification unit comprises:

the encryption information acquisition subunit is used for acquiring system encryption data information sent by the proxy node; the system encryption data information is obtained by the agent node through encrypting the initial transaction data and the signature information through the system public key of the core consensus network; the signature information is obtained after the agent node signs the initial transaction data through the node private key of the agent node when the agent node obtains the initial transaction data sent by the service node in the service network;

the decryption subunit is used for decrypting the system encrypted data information through a system private key corresponding to the system public key to obtain initial transaction data and signature information;

the signature verification subunit 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 transaction verification subunit is used for performing transaction verification on the initial transaction data when the signature verification result indicates that the signature verification is successful, and determining a transaction verification result of the initial transaction data.

The block information of the block to be verified comprises transaction data to be processed, and the initial transaction data is transaction data in the transaction data to be processed;

the structure information determination module includes:

the system comprises a list acquisition unit, a first node and a second node, wherein the list acquisition unit is used for acquiring a first list and a second list which are maintained by the first node at a first time; the first list comprises first node identifications of nodes having a network connection relationship with the first node at a first time; the second list comprises second node identifications of nodes accessing the core consensus network at the first moment;

a node determining unit, configured to determine a node identifier list maintained by the first node at the second time based on a first node identifier in the first list and a second node identifier in the second list, and determine a second node to be broadcasted from the node identifier list; the second moment is the next moment of the first moment;

the predicted transaction determining unit is used for acquiring a network switching state of the second node from a first time to a second time, determining predicted auxiliary information of the second node based on the network switching state, and determining predicted transaction data used for being sent to the second node from the transaction data to be processed based on the predicted auxiliary information;

the target transaction identification determining unit is used for taking the transaction data except the predicted transaction data as target transaction data in the transaction data to be processed, and performing hash identification conversion on the target transaction data based on an identifier determining rule to obtain a target transaction identifier corresponding to the target transaction data;

and the structure information generating unit is used for generating first structure information of the compact block corresponding to the block to be verified based on the block header information, the predicted transaction data and the target transaction identifier in the block information.

Wherein the target transaction identification determination unit includes:

the target transaction determining subunit is used for taking the transaction data except the predicted transaction data as target transaction data in the transaction data to be processed;

an identification rule obtaining subunit, configured to obtain an identifier determination rule including a first hash rule and a second hash rule; the first hash rule is different from the second hash rule;

the first hash conversion subunit is used for performing first hash conversion on the target transaction data based on a first hash rule to obtain a first hash value corresponding to the target transaction data;

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

The core consensus network comprises a third node; the third node is a node other than the first node and the second node; the third node is used for identifying the blocks to be verified together when receiving second structure information of the compact blocks corresponding to the blocks to be verified;

the device also includes:

the consensus result analysis module is used for taking the first consensus result and the second consensus result as target consensus results and carrying out result analysis on the target consensus results when receiving the first consensus result returned by the third node and the second consensus result returned by the second node;

and the block writing module is used for determining that the consensus on the block to be verified is achieved and writing the block to be verified into a target block chain of the core consensus network if the target consensus result exceeding the consensus threshold value in the target consensus result indicates that the consensus is successful.

the structure information receiving module is used for receiving first structure information of a compact block corresponding to a block to be verified, which is sent by a first node in the core consensus network; the block to be verified is obtained by packaging the initial transaction data by the first node; the initial transaction data is forwarded by the service node in the service network through the proxy node; the agent node is used for carrying out network isolation on the service network and the core consensus network; the first structure information is determined by the first node based on the predicted prediction auxiliary information of the second node and the block information of the block to be verified;

the consensus module is used for acquiring a target transaction identifier from the first structure information and performing consensus on the to-be-verified blocks based on the target transaction identifier; the target transaction identifier is determined by the first node after hash identification conversion of the initial transaction data.

Wherein, this structure information receiving module includes:

a connection notification sending unit, configured to send a connection notification to a first node in a core consensus network based on a dense block connection mode, so that the first node uses block header information of a block to be verified as block header information to be confirmed; the connection notification is used for indicating that a compact block connection mode is adopted between the first node and the second node for data transmission;

the block head searching unit is used for receiving the block head information to be confirmed returned by the first node and searching historical block head information matched with the block head information to be confirmed in a node memory of the second node;

a block acquisition request sending unit, configured to send a block acquisition request to the first node if historical block header information matching the block header information to be confirmed is not found; the block acquisition request is used for indicating a first node to determine first structure information of a compact block corresponding to a block to be verified based on a compact block connection mode;

and the structure information receiving unit is used for receiving the first structure information sent by the first node.

The block information comprises transaction data to be processed, and the initial transaction data is transaction data in the transaction data to be processed;

the consensus module comprises:

a target transaction identifier acquisition unit for acquiring a target transaction identifier from the first structure information; the target transaction identifier is determined by the first node after performing hash identification conversion on target transaction data in the transaction data to be processed based on the identifier determination rule; the target transaction data is transaction data except the predicted transaction data in the transaction data to be processed; the predicted transaction data is the transaction data determined by the first node based on the prediction auxiliary information in the transaction data to be processed;

the local transaction identification determining unit is used for performing hash identification conversion on local transaction data in a second transaction pool of the second node based on the identifier determining rule to obtain a local transaction identifier corresponding to the 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, and acquiring key transaction data for reconstructing the to-be-verified block based on the comparison result;

and the consensus unit is used for performing consensus on the to-be-verified blocks based on the key transaction data and the first structure information.

Wherein, this sign comparison unit includes:

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

the transaction synchronization request generation subunit is configured to generate, based on the target transaction identifier, a transaction synchronization request for sending to the first node if the comparison result indicates that the target transaction identifier is different from the local transaction identifier, so that the first node obtains, based on the transaction synchronization request, target transaction data corresponding to the target transaction identifier from the to-be-processed transaction data in the block information;

and the key transaction determining subunit is used for taking the target transaction data as the key transaction data for reconstructing the to-be-verified block when receiving the target transaction data returned by the first node.

The first structure information comprises block header information and predicted transaction data of a block to be verified;

the consensus unit comprises:

the reconstruction subunit is used for reconstructing to obtain a to-be-verified block based on the key transaction data, the block header information and the predicted transaction data;

the to-be-compared tree root determining subunit is used for acquiring a Mercker path associated with the key transaction data, acquiring a key transaction hash value corresponding to the key transaction data and a path hash value in the Mercker path, and determining the to-be-compared tree root of the to-be-verified block;

and the consensus subunit is used for comparing the Mercker tree root in the block header information with the tree root to be compared and performing consensus on the block to be verified according to the comparison result.

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

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

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 the embodiment of the application, the proxy node can perform network isolation on the service network and the core consensus network in the blockchain network. In the process that the service node in the service network broadcasts the initial transaction data (i.e., the transaction data generated by the service node executing the transaction service) to the consensus node so that the first node (i.e., the consensus node) in the core consensus network packages the block, the initial transaction data needs to be uniformly broadcast to the core consensus network through the proxy node, and the initial transaction data does not need to be indiscriminately broadcast to all block chain nodes in the block chain network through the service node like a traditional block chain deployment manner, so that frequent broadcast of the transaction data inside the core consensus network can be effectively reduced. In addition, after the first node performs packing processing on the initial transaction data to obtain a block to be verified, the first node may generate structure information (i.e., first structure information) of a compact block corresponding to the block to be verified based on predicted prediction auxiliary information (used for predicting complete transaction data sent to the second node) of the second node and block information of the block to be verified, and may further directly send the first structure information to the second node, so that the second node may perform consensus on the block to be verified based on a target transaction identifier in the first structure information. The target transaction identifier is determined by the first node after performing hash identification conversion on the transaction data (e.g., initial transaction data) in the block to be verified. It can be understood that when the first node is in consensus with the to-be-verified block, the first structure information includes the target transaction identifier used for representing the transaction data, instead of the complete transaction data, so that the data traffic during data transmission can be reduced by the embodiment of the application, and the consensus performance can be improved.

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 disclosure;

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

fig. 5 is a schematic view of a scenario for generating a to-be-verified block according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a scenario for acquiring critical transaction data 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 flowchart of determining first structure information 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 structural diagram of a transaction data processing device according to an embodiment of the present application;

FIG. 12 is a schematic diagram of a computer device provided by an embodiment of the present application;

fig. 13 is a schematic structural diagram of a data processing system 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 blockchain consensus protocols. 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 four main capabilities: wallet, mine digging, block chain database, network routing. Each node has a routing function, but other functions are not necessarily all, and a general bitcoin core node has four functions. Such core nodes may participate in verifying, broadcasting transaction data and block information for blocks to be verified, 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 referred to as a full node (e.g., the consensus node 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 complete transaction Verification by means of "Simplified transaction Verification (SPV), and such nodes may be referred to as light nodes (Lightweight nodes) or SPV nodes (e.g., service nodes shown in fig. 1).

The user can view his own account balance through these light node wallets, manage wallet addresses and private keys, initiate transactions, etc. The excavation nodes may compete with other excavation nodes to create new blocks by solving a proof of workload (PoW) algorithm problem. Some mining nodes are also full nodes, i.e. complete blockchain databases are also stored, and such nodes are generally independent miners (Solo Miner). Still other mining nodes, which are not independently mined but are connected to the mine pit along with other nodes to participate in collective mining, are also commonly referred to as pit miners (Pool miners). This results in a local centralized pool network, with the central node being a pool server and the other mining nodes all connected to the pool server. The communication between the mine miners and the mine pool server does not adopt a standard bitcoin protocol, but uses a mine pool digging protocol, and the mine pool server is used as a full node and can use the bitcoin protocol of a main network when communicating with other bitcoin nodes. In addition, after the miners create a new block, the new block needs to be broadcast to the consensus nodes in the core consensus network shown in fig. 1, and after the core consensus network receives the block, the reward for the miners is valid, and then the next block hash calculation is started.

It is understood that the service network and the core consensus network shown in fig. 1 may be in different network environments, for example, in general, 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 two may interact through a routing boundary. Therefore, the hierarchical structure of 'business network-core consensus network' is adopted, so that consensus nodes in the core consensus network are safer, and further, frequent broadcasting of transaction data in the core consensus network can be reduced through an effective mechanism, and the overall consensus performance is improved.

To facilitate understanding, embodiments of the present application may select one node among the plurality of nodes in the service network shown in fig. 1 as a target service node for sending initial transaction data to the proxy node 10. For example, the embodiment of the present application may use the service node 110a shown in fig. 1 as a target service node. In addition, in the core consensus network shown in fig. 1, the consensus node for performing the packaging processing on the initial transaction data may be used as a first node, the first node may broadcast the block to be verified to other consensus nodes in the core consensus network, and the consensus node for performing the consensus on the block to be verified may be used as a second node, and the consensus nodes except the first node and the second node in the core consensus network may be used as third nodes. For example, the first node may be the node 120a in the core consensus network shown in fig. 1, and the second node may be the node 120b in the core consensus network shown in fig. 1. The third node may be a node other than node 120a and node 120b in the core consensus network.

It can be understood that, the proxy node 10 in the embodiment of the present application may uniformly broadcast the initial transaction data sent by the service node in the service network to the core consensus network, without frequently broadcasting the initial transaction data to all the blockchain nodes in the blockchain network through the service node like a common blockchain deployment manner, so that frequent broadcasting of the transaction data in the core consensus network may be effectively reduced. In addition, in the process of broadcasting the packed to-be-verified block to the core consensus network, the first node may transmit structure information (e.g., first structure information) of the compact block corresponding to the to-be-verified block, so that the second node in the core consensus network performs consensus on the to-be-verified block based on the target transaction identifier in the first structure information. 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 transaction data. Therefore, the target transaction identifier is transmitted by the first node instead of the complete transaction data, so that the data flow during data transmission can be effectively reduced, and the consensus performance is improved.

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 consensus node 20C in this embodiment may be a consensus node (i.e., a first node) for performing a packaging process on the initial transaction data, 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. The consensus node 20D in this embodiment may be a node to be broadcasted (i.e., a second node) selected by the first node in the core consensus network, for example, the consensus node 20D may be the node 120b in the core consensus network shown in fig. 1.

It should be understood that the service node in the service network may execute the transaction service to obtain the initial transaction data according to the transaction execution result of the transaction service, and may further transmit the initial transaction data to the agent node 20B. For example, the transaction service may be an asset transfer service, wherein the asset transfer service refers to transfer of virtual assets such as bitcoin, ether house, game gold, game diamond, or electronic ticket.

When receiving the initial transaction data, the agent node 20B may broadcast the initial transaction data to the core consensus network, so that the consensus node 20C in the core consensus network performs transaction verification on the initial transaction data to obtain a transaction verification result. The consensus node 20C may add the initial transaction data to the transaction pool (i.e., the first transaction pool) of the consensus node 20C when the transaction verification result indicates that the transaction verification is successful. It is understood that the consensus node 20C may obtain a transaction data set including initial transaction data in the first transaction pool, and may further perform a packing process on the transaction data in the obtained transaction data set, so as to obtain a to-be-verified block (e.g., to-be-verified block 200 x) to be broadcasted to the core consensus network.

In order to effectively reduce the frequent broadcasting of transaction data in the core consensus network and the data traffic during data transmission, the consensus node 20C and the consensus node 20D to be broadcasted may employ a compact block (compact block) connection mode, so that in the process of consensus on the block to be verified, the consensus node 20C may transmit the structure information of the compact block corresponding to the block to be verified 200x to the consensus node 20D, so that the consensus node 20D can agree on the block to be verified. It is understood that the consensus node 20C may obtain the consensus node 20D to be broadcasted from the core consensus network, and may determine the prediction assistance information of the consensus node 20D. The prediction assistance information may be used to predict the complete transaction data sent to the consensus node 20D, and for example, the prediction assistance information may include the network switching status of the consensus node 20D. If the consensus node 20D is in network connection with the consensus node 20C at a certain time (e.g., time t 1), fails to connect with the consensus node 20C due to a power failure or a network outage at a time next to time t1 (e.g., time t2, i.e., a first time), and re-connects with the consensus node 20C at a time next to time t2 (e.g., time t3, i.e., a second time), the consensus node 20C may determine the network switching status of the consensus node 20D as a re-access status, so as to predict the predicted transaction data for transmission to the consensus node 20A later.

Meanwhile, the common node 20C may also obtain the block information of the block 200x to be verified. The block information may include block header information and block body of the block to be verified 200 x. The block header information may include information such as a hash value of a parent block of the block to be verified 200x, a block height, a version number, a timestamp, a difficulty value, a random number, and a root of a merkel tree. The tile body may include transaction data (i.e., pending transaction data) packed into the transaction data set of the to-be-verified tile 200x and a mercker path formed by transaction hash values of the pending transaction data. The pending transaction data may include money-creating transaction data, initial transaction data, and complete transaction data transmitted by other service nodes.

Further, the consensus node 20C may obtain structure information (e.g., the structure information 200y shown in fig. 2, i.e., the first structure information) of the dense block corresponding to the block to be verified 200x based on the predicted prediction auxiliary information of the consensus node 20D and the block information of the block to be verified. The structure information 200y may include the block header information, the target transaction identifier and the predicted transaction data of the block 200x to be verified. Among the transaction data to be processed in the block to be verified, the transaction data determined based on the prediction auxiliary information and used for being sent to the consensus node 20D may be referred to as predicted transaction data, and the transaction data except the predicted transaction data may be referred to as target transaction data. For example, the predicted transaction data may include: the first transaction in the block to be verified (referred to as a money creation transaction or a coinbase transaction), the transaction data forwarded by the proxy node 20B received by the consensus node 20C when the consensus node 20D drops (e.g., time t2 to time t 3). The target transaction identifier is determined after hash identification conversion is performed on target transaction data, and the target transaction identifier may be a hash value of a shorter byte (for example, 6 bytes), so that traffic data during data transmission can be effectively reduced, and the consensus node 20D receiving the target transaction identifier can reduce data processing pressure, thereby effectively preventing denial of service attack.

Further, the consensus node 20C may broadcast the structure information 200y to the consensus node 20D. The consensus node 20D may determine, based on the target transaction identifier in the structural information 200y, key transaction data used to reconstruct the to-be-verified block 200x, and further may reconstruct, based on the key transaction data and the structural information 200y, the to-be-verified block 200x, and perform consensus on the to-be-verified block 200 x.

It should be understood that in a hierarchical blockchain structure of a service network-core consensus network, the proxy node 20B may uniformly broadcast the initial transaction data sent by the service node in the service network to the core consensus network, without broadcasting to all blockchain nodes in the blockchain network, as in a common blockchain deployment manner. Meanwhile, after the initial transaction data is packaged and the to-be-verified block 200x is obtained, the consensus node 20C needs to perform consensus on the to-be-verified block 200x in the core consensus network, and does not need to perform consensus in the whole block chain network, so that frequent broadcasting of the transaction data in the core consensus network can be effectively reduced. In addition, in the process of broadcasting the to-be-verified block 200x to the consensus node 20D, the consensus node 20C does not directly broadcast the to-be-verified block 200x, but transmits the structure information 200y of the compact block corresponding to the to-be-verified block 200x, so that the consensus node 20D can perform consensus on the to-be-verified block 200x based on the target transaction identifier in the structure information 200 y. Because the structure information 200y includes the target transaction identifier for representing the target transaction data, rather than the complete target transaction data, the data traffic during data transmission can be effectively reduced, and the network storm is reduced, so as to improve the consensus performance.

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. The specific implementation manner of the second node for performing network isolation on the to-be-verified block based on the target transaction identifier in the structural information may refer to the embodiments corresponding to fig. 3 to 9 described below, where the specific implementation manner of the second node for performing network isolation on the to-be-verified block based on the target transaction identifier in the structural information may be that initial transaction data sent by a service node in the service network is acquired, and the initial transaction data is sent to a first node in the core consensus network, so that the first node performs a packing process on the initial transaction data to obtain the to-be-verified block, and then when the first node broadcasts the to-be-verified block, the first node may transmit structural information of the to-be-verified block to the second node based on a dense block connection mode.

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 node in a core consensus network, where the first node may be a server accessed to the core consensus network or a user terminal accessed to the core consensus network, and a specific form of the first node is not limited herein. The first node may be any one of the above-mentioned core consensus networks shown in fig. 1, for example, node 120 a. The method may comprise at least the following steps S101-S103:

step S101, acquiring initial transaction data forwarded by the agent node, and packaging the initial transaction data to obtain a to-be-verified block to be broadcasted to the core consensus network.

Specifically, the first node may obtain initial transaction data forwarded by the service node in the service network through the proxy node, and perform transaction verification on the initial transaction data to obtain a transaction verification result. When the transaction verification result indicates that the transaction verification is successful, the first node may add the initial transaction data to a first transaction pool of the first node, and may obtain a transaction data set including the initial transaction data from the first transaction pool, and use the transaction data in the transaction data set as the transaction data to be processed. Further, the first node may perform transaction hash conversion on the transaction data to be processed to obtain a transaction hash value corresponding to the transaction data to be processed, and determine the root of the merck tree corresponding to the transaction data to be processed based on the transaction hash value. Meanwhile, the first node may obtain the first chunk with the largest generation timestamp from a target chunk chain of the core consensus network, and may use the chunk hash value of the first chunk as a parent chunk hash value of a next chunk of the first chunk. It should be understood that the first node may generate a next chunk of the first chunk based on the pending transaction data, the mercker tree root, and the parent chunk hash value, and treat the generated next chunk of the first chunk as the to-be-verified chunk to be written to the target chain of chunks. The generation timestamp of the to-be-verified block can be used to update the maximum generation timestamp on the target blockchain.

It should be understood that a service node in the service network may execute a transaction service to obtain initial transaction data according to a transaction execution result of the transaction service. Further, the service node may send the initial transaction data to the proxy node, so that the proxy node performs permission verification on the service node, thereby obtaining a permission verification result. The authority verification here may include verifying whether node identification information of the service node belongs to a node identification in an illegal node list, whether a transaction format of the initial transaction data is wrong, or the like. It is understood that the illegal node list may refer to a blacklist stored by the proxy node, and the illegal nodes corresponding to the illegal node identifiers in the illegal node list may include detected malicious nodes, nodes reported by others, nodes with abnormal transaction frequency sent in a certain period of time, and the like.

It can be understood that, when the agent node receives the initial transaction data sent by the service node, the node identification information of the service node may be searched in the illegal node list 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 initial transaction data does not need to be broadcasted to the core consensus network. If the permission verification result indicates that the illegal node identifier identical to the node identifier information is not found in the illegal node list, the proxy node may determine that the permission verification result belongs to a legal verification result. At this time, the proxy node may determine that the service node is a valid node, and may broadcast the initial transaction data to the core consensus network.

The proxy node may sign the initial transaction data through a node private key of the proxy node to obtain signature information corresponding to the initial transaction data. Further, the agent node may obtain a system public key of the core consensus network, and encrypt the initial transaction data and the signature information to obtain system encrypted data information. At this time, the proxy node may send the system encrypted data information to the first node in the core consensus network. When the first node receives the system encrypted data information, the first node can decrypt the system encrypted data information through a system private key corresponding to the system public key, and then can obtain initial transaction data and signature information. Further, the first node may obtain a node public key of the agent node, and check the signature of 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 node may perform transaction verification on the initial transaction data, and determine a transaction verification result of the initial transaction data. Transaction verification here may include balance verification, double payment determination, etc.

For example, in an electronic ticket scenario, the initial transaction data may transfer an electronic ticket for service node a to service node B. At this time, the first node needs to search the historical transaction information of the electronic ticket in the target block chain in the core consensus network, for example, determine whether the electronic ticket exists in the account of the service node a, whether the accounts of the service node a and the service node B are wrong, the source of the electronic ticket owned by the service node a, and the like.

When the transaction verification result indicates that the transaction verification fails, the first node may determine that the initial transaction data is illegal transaction data, and may further send an uplink failure notification to the service node to notify the service node that the initial transaction data cannot be successfully written into the target block chain. When the transaction verification result indicates that the transaction verification is successful, the first node may add the initial transaction data to a transaction pool (i.e., a first transaction pool) of the first node, so as to perform a subsequent packaging process to obtain a block to be verified.

For ease of understanding, please refer to fig. 4, where fig. 4 is a schematic view of a scenario for acquiring initial transaction data according to an embodiment of the present application. As shown in fig. 4, the service node 40A in the embodiment of the present application may be a node for executing a transaction service, and the service node 40A may be any one of the service nodes in the service network shown in fig. 1, for example, the node 110A. The consensus node 40C in this embodiment may be a first node for performing a packet processing, and the consensus node 40C 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 40B in the embodiment of the present application may be configured to perform network isolation between the service network and the core consensus network, and the proxy node 40B may be the proxy node 10 shown in fig. 1.

It should be understood that the service node 40A in the embodiment of the present application may send initial transaction data (e.g., the transaction data 4 shown in fig. 4) generated when the transaction service is executed to the proxy node 40B shown in fig. 4, so that the proxy node 40B broadcasts the transaction data 4 to the core consensus network. It can be understood that, since the service network is generally in a public network and can be accessed by other uncertain network terminals, the core consensus network is in a relatively secure private cloud, and mutual access of the core consensus network inherently ensures security by a consensus mechanism without additional addition of identity management and network control. Therefore, the process of broadcasting the transaction data 4 to the core consensus network by the proxy node 40B needs to be strictly controlled. In other words, when the authority verification result is determined to be a valid verification result, the proxy node 40B may sign the transaction data 4 based on the node private key of the proxy node 40B, and obtain signature information corresponding to the transaction data 4. It is understood that the proxy node 40B may perform a hash calculation on the transaction data 4, so as to obtain the digest information h of the transaction data 4, and digitally sign the digest information h based on the node private key of the proxy node 40B, so as to obtain the signature information corresponding to the transaction data 4.

Further, the agent node 40B may obtain a system public key of the core consensus network, and encrypt the transaction data 4 and the signature information to obtain system encrypted data information. At this time, the proxy node 40B may transmit the system encrypted data information to the consensus node 40C in the core consensus network.

When receiving the system encrypted data information, the consensus node 40C may decrypt the system encrypted data information through a system private key corresponding to the system public key (i.e., the system private key of the core consensus network), so as to obtain the transaction data 4 and the signature information. Further, the consensus node 40C may obtain a node public key of the agent node 40B, and check the signature information based on the node public key to obtain a signature check result. It can be understood that the consensus node 40C may verify the digital signature in the signature information based on the node public key of the agent node 40B to obtain the digest information H of the transaction data 4, and perform hash calculation on the transaction data 4 by using the same hash algorithm as that of the agent node 40B, so as to obtain the digest information H of the transaction data 4. Further, the consensus node 40C may compare the digest information H obtained after the signature verification with the digest information H obtained by performing the hash calculation 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 signature verification of the consensus node 40C fails. 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 consensus node 40C is successful, and thus the transaction data 4 can be obtained.

At this time, the consensus node 40C may perform transaction verification on the transaction data 4 and determine a transaction verification result of the transaction data 4. When the transaction verification result indicates a failure of transaction verification, the consensus node 40C may determine that the transaction data 4 is illegal transaction data, and may further send a notification message of uplink transaction failure to the service node 40A. When the transaction verification result indicates that the transaction verification is successful, the consensus node 40C may add the transaction data 4 to the transaction pool 400 of the consensus node 40C, so as to perform a subsequent packaging process to obtain a block to be verified.

Further, the first node may obtain a transaction data set including initial transaction data from the first transaction pool, and may generate a to-be-verified block to be broadcast to the core consensus network based on the transaction data (i.e., to-be-processed transaction data) in the transaction data set. For easy understanding, please refer to fig. 5, and fig. 5 is a schematic view of a scenario for generating a to-be-verified block according to an embodiment of the present application. As shown in fig. 5, the consensus node 50C in the embodiment of the present application may be a first node in a core consensus network, and the consensus node 50C 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 blockchain 5 shown in fig. 5 may be a target blockchain in the core consensus network shown in fig. 1, and the blockchain 5 may be an identical blockchain shared by each consensus node in the core consensus network to which the consensus node 50C belongs, and each consensus node may obtain information stored in the blockchain 5. The blockchain 5 includes a block 50a, a block 50b, …, and a block 50n, where the block 50a may be referred to as a foundational block of the blockchain 5.

It should be understood that the transaction pool 500 (i.e., the first transaction pool) shown in fig. 5 may have stored therein a plurality of transaction data forwarded by the agent node. The plurality of transaction data may specifically include transaction data 1, transaction data 2, transaction data 3, …, transaction data m. Where m is a positive integer. The transaction data 2 may be initial transaction data forwarded by a service node (e.g., node 110a shown in fig. 1) in the service network through a proxy node.

It is understood that the consensus node 50C may obtain the transaction data set for packaging from the transaction pool 500 and use the transaction data in the transaction data set as pending transaction data. For example, transaction data 1, transaction data 2, transaction data 3, and transaction data 4 in the transaction data set may all be collectively referred to as pending transaction data. Further, the consensus node 50C may perform a transaction hash conversion on each transaction data in the transaction data set to obtain a corresponding transaction hash value. For example, the transaction Hash value for transaction data 1 is transaction Hash value 1 (e.g., Hash 1), the transaction Hash value for transaction data 2 is transaction Hash value 2 (e.g., Hash 2), the transaction Hash value for transaction data 3 is transaction Hash value 3 (e.g., Hash 3), and the transaction Hash value for transaction data 4 is transaction Hash value 4 (e.g., Hash 4). Further, the consensus node 50C may determine the root of the mercker tree corresponding to the transaction data to be processed based on the transaction hash value 1, the transaction hash value 2, the transaction hash value 3, and the transaction hash value 4.

Further, the consensus node 50C may obtain the first block (e.g., block 50 n) with the largest generation timestamp on the block chain 5 shown in fig. 5, and may further use the block hash value of the block 50n as the parent block hash value of the next block of the block 50 n. At this time, the consensus node 50C may generate a next block of the block 50n based on the transaction data to be processed, the mercker tree root, and the parent block hash value, and use the next block of the generated first block as a block to be verified to be written into the block chain 5. The generation timestamp of the block to be verified here can be used to update the maximum generation timestamp on the block chain 5. As shown in fig. 5, the block to be verified may include block header information and a block body. The block header information may include a parent block hash value, a version number, a timestamp, a difficulty value, a random number, a root of a merkel tree, and the like. The block body may store therein the to-be-processed transaction data packaged by the consensus node 50C and a mercker path formed by transaction hash values of the to-be-processed transaction data.

Step S102, a second node is obtained from the core consensus network, and first structure information of a dense block corresponding to the block to be verified is obtained based on the predicted prediction auxiliary information of the second node and the block information of the block to be verified.

Specifically, the first node may obtain a first list and a second list maintained by the first node at a first time. Wherein, the first list may include a first node identifier of a node having a network connection relationship with the first node at a first time; the second list here may comprise a second node identification of the node accessing the core consensus network at the first time instant. At this time, the first node may determine, based on the first node identifier in the first list and the second node identifier in the second list, a node identifier list maintained by the first node at the second time, and may further determine, from the node identifier list, the second node to be broadcasted. Here, the second time may be a time next to the first time. Further, the first node may acquire a network switching status of the second node from the first time to the second time, determine the predictive assistance information of the second node based on the network switching status, and may determine the predictive transaction data for transmission to the second node from the pending transaction data based on the predictive assistance information. It should be understood that, in the transaction data to be processed, the first node may use transaction data other than the predicted transaction data as target transaction data, and may further perform hash identification conversion on the target transaction data based on the identifier determination rule to obtain a target transaction identifier corresponding to the target transaction data. At this time, the first node may generate first structure information of the dense block corresponding to the block to be verified based on the block header information, the predicted transaction data, and the target transaction identifier in the block information. Here, the first structure information refers to structure information of a dense block corresponding to a block to be verified, which is generated by the first node based on the predicted prediction auxiliary information of the second node.

The block information of the block to be verified generated by the first node may include: block header information and a block body. The block header information may include information such as a parent block hash value, a block height, a version number, a timestamp, a difficulty value, a random number, and a root of the mercker tree of the block to be verified. The block body may include the transaction data to be processed packed into the block to be verified and the merckel path formed by the transaction hash value of the transaction data to be processed. It is understood that both the money creation transaction data and the initial transaction data belong to the transaction data in the transaction data to be processed. The money-creating transaction data refers to the first transaction in the block to be verified, which is also called a coin transaction. The transaction input of the money creation transaction data does not have a UTXO, nor an "input script". This field is replaced by the coinbase data, and the miners (i.e. the first node) can optionally fill any data with any other part of the coinbase, except the first few bytes. The transaction output of the money-creating transaction data is constructed by miners who win the mine and pays money-creating rewards and miner fees to the address of the wallet.

It can be understood that each consensus node in the core consensus network may store the node identifiers of other consensus nodes in the core consensus network in the node identifier list, so as to broadcast the generated to-be-verified block to other consensus nodes in the core consensus network subsequently according to the node identifiers in the node identifier list. 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 identifier list may store the node identifier of the node having the network connection relationship with the first node at the second time. The list of node identifications is determined based on a first node identification in a first list maintained at a first time and a second node identification in a second list. 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

It will be appreciated that the above-described,the first node in the embodiment of the present application may determine, from the node identification list, a second node to be broadcasted (e.g., the consensus node D shown in table 1)₁). For example, if node D is known₁A network connection is made with a first node at a certain time (e.g., time t 1), a connection with the first node is failed due to a power failure or a network disconnection at a time next to time t1 (e.g., time t2, i.e., the first time), and a network connection is made again with the first node at a time next to time t2 (e.g., time t3, i.e., the second time), so that the first node may determine that the consensus node D is a node D₁And the network switching state from the first time to the second time is a re-access state. At this time, the first node may determine the consensus node D based on the network switching status of the re-access status₁The prediction assistance information of (1). Due to the common knowledge of the node D₁Is in a dropped state from the time t2 to the time t3, and therefore the node D is commonly identified₁May not receive the transaction data broadcast by the agent node from time t2 to time t 3.

Therefore, in the process of determining the first structure information, if the transaction data to be processed in the block to be verified includes the transaction data received from time t2 to time t3, the first node needs to use the complete transaction data of the time period and the money-creating transaction data in the transaction data to be processed as the predicted transaction data. Meanwhile, in the transaction data to be processed, the first node may use the transaction data except the predicted transaction data as target transaction data, and may further perform hash identification conversion on the target transaction data based on an identifier determination rule to obtain a target transaction identifier corresponding to the target transaction data.

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 node may perform a first hash conversion on the target transaction data based on the first hash rule, to obtain a first hash value corresponding to the target transaction data. Further, the first 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 target transaction data, and obtain a target transaction identifier corresponding to the target 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 and fixes 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 node may perform a first hash conversion on the target transaction data to which the random number is added in 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 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 target transaction data. At this time, the first 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 target transaction identifier corresponding to the target transaction data.

Further, the first node may generate a transaction identifier for the identified node D based on the block header information, the predicted transaction data, and the target transaction identifier in the block information₁And sending first structure information of the compact block corresponding to the block to be verified.

Step S103, broadcasting the first structure information to the second node, so that the second node recognizes the to-be-verified block based on the target transaction identifier.

In particular, the first node may broadcast the first structure information to the second node. When the second node receives the first structure information, the target transaction identifier in the first structure information may be obtained. Further, the second node may obtain the identifier determination rule, and perform hash identification conversion on the local transaction data in the transaction pool of the second node (i.e., the second transaction pool), so as to obtain a local transaction identifier corresponding to the local transaction data. At this time, the second node may compare the local transaction identifier with the target transaction identifier to obtain a comparison result, and may further obtain, based on the comparison result, key transaction data for reconstructing the to-be-verified block. It will be appreciated that the second node may agree on the block to be verified based on the critical transaction data and the first configuration information.

It should be understood that when the second node acquires the key transaction data for reconstructing the to-be-verified block, the second node may compare the local transaction identifier with the target transaction identifier to obtain a comparison result. If the comparison result indicates that the target transaction identifier is the same as the local transaction identifier, the second node may use, in the second transaction pool, the local transaction data corresponding to the local transaction identifier as the key transaction data for reconstructing the to-be-verified block. Optionally, if the comparison result indicates that the target transaction identifier is different from the local transaction identifier, the second node may generate a transaction synchronization request for sending to the first node based on the target transaction identifier, so that the first node obtains target transaction data corresponding to the target transaction identifier in the to-be-processed transaction data in the block information based on the transaction synchronization request. Further, when receiving the target transaction data returned by the first node, the second node may use the target transaction data as the key transaction data for reconstructing the to-be-verified block.

It is understood that the second node may reconstruct the to-be-verified block based on the critical transaction data, the block header information included in the first structure information, and the predicted transaction data. The second node may further obtain a tacher path associated with the key transaction data based on the reconstructed to-be-verified block, and obtain a key transaction hash value corresponding to the key transaction data and a path hash value in the tacher path, so as to determine a tree root to be compared of the to-be-verified block. Further, the second node may compare the root of the mercker tree in the block header information with the root of the tree to be compared, and identify the block to be verified according to the comparison result.

For ease of understanding, please refer to fig. 6, and fig. 6 is a schematic view of a scenario for acquiring critical transaction data according to an embodiment of the present application. As shown in fig. 6, the consensus node 60C in this embodiment may be a first node, and 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 consensus node 60D in this embodiment may be a second node to be broadcasted, and the consensus node 60D may be any one of the nodes in the core consensus network shown in fig. 1, for example, the node 120 b.

The structure information 600y shown in fig. 6 may be the structure information (i.e., the first structure information) of the dense block corresponding to the block to be verified generated by the consensus node 60C. The block to be verified may be the block to be verified shown in fig. 5. It is understood that the block header information of the block to be verified shown in fig. 5, the predicted transaction data (e.g., transaction data 1 and transaction data 2 shown in fig. 5), and the target transaction identifier (e.g., transaction identifier c corresponding to transaction data 3 and transaction identifier d corresponding to transaction data 4 shown in fig. 5) may be included in the structure information 600 y.

It should be appreciated that the consensus node 60C may send the structure information 600y to the consensus node 60D. When the consensus node 60D receives the structure information 600y, the target transaction identifier in the structure information 600y may be obtained. Further, the consensus node 60D may obtain an identifier determination rule for determining the target transaction identifier, and perform hash identification conversion on the local transaction data in the transaction pool 600 (i.e., the second transaction pool 600) of the consensus node 60D to obtain a local transaction identifier corresponding to the local transaction data.

As shown in fig. 6, the local transaction data in the transaction pool 600 may include transaction data 3 and transaction data 5. It will be appreciated that the local transaction identifier determined by consensus node 60D may include transaction identifier c as well as transaction identifier e. The transaction identifier c may be a transaction identifier corresponding to the transaction data 3, and the transaction identifier e may be a transaction identifier corresponding to the transaction data 5. It can be understood that, for a specific implementation of determining the local transaction identifier corresponding to the local transaction data by the consensus node 60D, reference may be made to the above specific implementation of determining the target transaction identifier corresponding to the target transaction data by the first node, and details will not be further described here.

The consensus node 60D 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 1). The comparison result 1 may indicate that the transaction identifier c in the target transaction identifier is the same as the transaction identifier c in the local transaction identifier, and at this time, the consensus node 60D may use, in the local transaction data in the transaction pool 600, the transaction data 3 corresponding to the transaction identifier c as the key transaction data for reconstructing the to-be-verified block.

Further, the consensus node 60D 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 2). The comparison result 2 may indicate that the transaction identifier D in the target transaction identifier is different from both the transaction identifier C and the transaction identifier e in the local transaction identifier, and at this time, the consensus node 60D may generate a transaction synchronization request for sending to the consensus node 60C based on the transaction identifier D. When receiving the transaction synchronization request, the consensus node 60C may obtain the transaction data 4 corresponding to the transaction identifier D from the to-be-processed transaction data included in the block information, and send the transaction data 4 to the consensus node 60D. Further, the consensus node 60D, upon receiving the transaction data 4, may use the received transaction data 4 as key transaction data for reconstructing the to-be-verified block.

It should be appreciated that the consensus node 60D may reconstruct the to-be-verified block based on the critical transaction data, the block header information in the structure information 600y, and the predicted transaction data. Further, the consensus node 60D may obtain a merkel path associated with the critical transaction data from the block to be verified, and may further obtain a path hash value in the merkel path. For example, the block to be verified reconstructed by the common node 60D may be the block to be verified shown in fig. 5, that is, the path Hash value in the merkel path acquired by the second node may be Hash12 or Hash 1234.

Further, the consensus node 60D may perform transaction hash conversion on the key transaction data (e.g., the transaction data 3 in the transaction pool 600 and the transaction data 4 sent by the consensus node 60C), obtain a key transaction hash value corresponding to the key transaction data, and determine the tree root to be compared of the block to be verified. At this time, the consensus node 60D may compare the root of the mercker tree in the block header information with the root of the tree to be compared, and perform consensus on the block to be verified according to the comparison result to obtain a consensus result. It is understood that when the merkel root is not consistent with the root to be compared, the embodiment of the present application may consider that the consensus result of the consensus node 60D indicates a failure in consensus. Alternatively, when the merkel tree root is consistent with the data to be compared, the embodiment of the present application may consider that the consensus result of the consensus node 60D indicates that the consensus is successful.

In the embodiment of the application, the proxy node can perform network isolation on the service network and the core consensus network in the blockchain network. In the process that the service node in the service network broadcasts the generated initial transaction data to the consensus node so that the first node (i.e., the consensus node) in the core consensus network packages the block, the initial transaction data needs to be uniformly broadcast to the core consensus network through the proxy node, and the service node does not need to frequently broadcast to all block chain nodes in the block chain network like a traditional block chain deployment manner, so that the frequent broadcast of the transaction data in the core consensus network can be effectively reduced. It can be understood that since the initial transaction data does not need to be broadcast in the service network, the security and privacy of the initial transaction data can be ensured. In addition, after the first node performs packing processing on the initial transaction data to obtain a to-be-verified block, the first node may generate structure information (i.e., first structure information) of a compact block corresponding to the to-be-verified block based on prediction auxiliary information (used for predicting complete transaction data sent to the second node) of the second node to be broadcasted and block information of the to-be-verified block, and may further directly send the first structure information to the second node, so that the second node may perform consensus on the to-be-verified block based on a target transaction identifier in the first structure information. The target transaction identifier is determined by the first node after performing hash identification conversion on the transaction data (e.g., initial transaction data) in the block to be verified. It can be understood that when the first node recognizes the to-be-verified block, the first structure information includes the target transaction identifier for representing the complete transaction data, instead of the complete transaction data, so that the embodiment of the application can reduce data traffic during data transmission and improve recognition performance.

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 jointly by a service node in a service network, a proxy node, a first node in a core consensus network, and a second node. The service node may be any one of the common nodes in the service network shown in fig. 1, e.g., node 110 a. The proxy node may be the proxy node 10 shown in figure 1 above. The first node may be any one of the above-mentioned core consensus networks shown in fig. 1, for example, node 120 a. The second node may be a consensus node to be broadcasted in the core consensus network shown in fig. 1, e.g., node 120 b. The method may comprise at least the following steps S201-S206:

step S201, a service node sends initial transaction data to an agent node;

step S202, the agent node forwards initial transaction data to the first node;

step S203, when the first node acquires the initial transaction data forwarded by the proxy node, packaging the initial transaction data to obtain a to-be-verified block to be broadcasted to the core consensus network;

in step S204, the first node acquires the second node from the core consensus network, and obtains the first structure information of the dense block corresponding to the block to be verified based on the predicted prediction auxiliary information of the second node and the block information of the block to be verified.

Specifically, the second node may send a connection notification to the first node in the core consensus network based on the tight block connection mode, so that the first node uses the block header information of the block to be verified as the block header information to be confirmed. The connection notification here may be used to indicate that the tight block connection mode is adopted for data transmission between the first node and the second node. Further, when receiving the connection notification, the first node may use the block header information of the block to be verified as the block header information to be confirmed, and send the block header information to be confirmed to the second node, so that the second node searches the historical block header information matched with the block header information to be confirmed in the node memory of the second node. It should be appreciated that if the second node does not find historical chunk header information that matches the chunk header information to be confirmed, the second node may send a chunk obtaining request to the first node. When the first node receives the block acquisition request, the first node may determine first structure information of a compact block corresponding to the block to be verified based on a compact block connection mode, and may further send the first structure information to the second node, so that the second node recognizes the block to be verified based on a target transaction identifier in the first structure information.

For ease of understanding, please refer to fig. 8, where fig. 8 is a schematic flowchart of a process for determining the first structure information according to an embodiment of the present application. As shown in fig. 8, the consensus node 80C in the embodiment of the present application may be a first node, and the consensus node 80C may be any one of the nodes in the core consensus network shown in fig. 1, for example, the node 120 a. The consensus node 80D in this embodiment may be a second node to be broadcasted, and the consensus node 80D may be any one of the nodes in the core consensus network shown in fig. 1, for example, the node 120 b.

As shown in fig. 8, the consensus node 80D may perform step S81 to send a connection notification to the consensus node 80C in the core consensus network based on the dense block connection mode. Here, the connection notification may be used to instruct the common node 80C and the common node 80D to perform data transmission using the dense block connection mode. When the common node 80C receives the connection notification, step S82 may be executed to use the block header information of the block to be verified as the block header information to be verified, and step S83 may be further executed to send the block header information to be verified to the common node 80D, so that the common node 80D can determine whether the block header information to be verified exists in the node memory, thereby effectively preventing the structure information of the dense block corresponding to the block to be verified from being repeatedly transmitted.

Further, when the consensus node 80D receives the to-be-confirmed block header information, step S84 may be executed to search the node memory of the consensus node 80D for the historical block header information matching the to-be-confirmed block header information, so as to obtain the search result. The historical block header information herein may refer to block header information broadcast by other consensus nodes in the core consensus network. It should be understood that if the consensus node 80D finds the historical block header information matching the block header information to be confirmed in the node memory, it can be regarded that other consensus nodes in the core consensus network have broadcast the structure information of the compact block corresponding to the block to be verified to the consensus node 80D, so that the consensus node 80D performs consensus on the block to be verified, and at this time, the consensus node 80C does not need to send the structure information of the compact block corresponding to the block to be verified to the consensus node 80D, so as to effectively avoid frequent consensus of the block to be verified by the consensus node 80D, and further improve the overall consensus performance. Optionally, if the consensus node 80D does not find the historical chunk header information matching the chunk header information to be confirmed, it is determined that the consensus node 80D does not agree on the chunk to be verified, and at this time, the consensus node 80D may execute step S84 to generate a chunk obtaining request for obtaining the first structure information.

Further, the consensus node 80D may perform step S85 to send a tile obtaining request to the consensus node 80C. When the consensus node 80C receives the chunk obtaining request, the consensus node may perform step S86 to determine the first structure information of the dense chunk corresponding to the chunk to be verified based on the dense chunk connection mode.

Step S205, the first node broadcasts the first structure information to the second node;

in step S206, the second node obtains the target transaction identifier from the first structure information, and recognizes the to-be-verified block based on the target transaction identifier.

For specific implementation of steps S201 to S206, reference may be made to the description of steps S101 to S103 in the embodiment corresponding to fig. 3, and details will not be described here.

It should be understood that in the core consensus network, the node other than the first node and the second node may be referred to as a third node in the embodiments of the present application. The third node may be configured to perform consensus on the to-be-verified block when receiving the second structure information of the dense block corresponding to the to-be-verified block. The second structure information here refers to the structure information of the dense block corresponding to the block to be verified, which is generated by the first node based on the prediction auxiliary information of the third node. For a specific implementation manner of the third node for identifying the block to be verified, reference may be made to the specific implementation manner of the second node for identifying the block to be verified, and details will not be described here again.

It can be understood that, in the embodiment of the present application, the consensus result returned by the third node may be referred to as a first consensus result, and the consensus node returned by the second result may be referred to as a second consensus result. When the first node receives a first consensus result returned by the third node and a second consensus result returned by the second node, the first consensus result and the second consensus result may be used as a target consensus result, and result analysis may be performed on the target consensus result. If it is determined in the target consensus result that there is a target consensus result exceeding a consensus threshold (e.g., 1/2) indicating a successful consensus, the first node may determine that consensus on the to-be-verified tile is achieved and write the to-be-verified tile to the target tile chain of the core consensus network.

As shown in fig. 5, when determining that the consensus on the to-be-verified block is achieved, the consensus node 50C (i.e., the first node) may write the to-be-verified block into the blockchain 5, that is, successfully write the initial transaction data generated by the service node in the service network into the blockchain 5 in the core consensus network corresponding to the consensus node 50C.

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 block chain maintained by a tax office 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, and 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 node in the service layer may include terminal devices corresponding to electronic tax bureaus, terminal devices corresponding to enterprise users, and terminal devices corresponding to consuming users. 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 a service node (e.g., terminal device a corresponding to a 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.

Wherein, the proxy node in the routing proxy layer can be used for network isolation of the service layer and the core consensus network layer, and the proxy node can have point-to-point service (i.e. P2P service), routing service, certificate cache and 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 the basic functions of nodes 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 for information can be realized based on a public key certificate system. The public key certificate system may include public and private key passwords, x509 certificates, CA certificate issuing centers, 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 is to be understood that, in the embodiment of the present application, the proxy node may forward the initial transaction data sent by the service node in the service layer to the core consensus network layer. In the forwarding process, the agent node can confirm the legality of the service node, when the service node is confirmed to be a legal node, transaction format verification is carried out on initial transaction data, further when the transaction format is confirmed to be correct, the initial transaction data can be signed to obtain signature information, the initial transaction data and the signature information are encrypted to obtain system encrypted data information, and the system encrypted data information is sent to the core consensus network layer.

The consensus node (i.e., the accounting node) in the core consensus network layer may be a trusted node in the tax private network, and may perform consensus on the initial transaction data forwarded by the proxy node and the to-be-verified block by invoking an authority contract (e.g., an intelligent contract). It is understood that each consensus node may receive the initial transaction data forwarded by the agent node, perform transaction verification on the initial transaction data, and store the initial transaction data in a transaction pool (i.e., the cache shown in fig. 9) when the transaction verification result indicates that the transaction verification is successful. The transaction data added to the transaction pool in the embodiment of the application can be called local transaction data. In addition, each consensus node has the capability of packaging the block, namely the consensus node can select transaction data to be processed from local transaction data of the transaction pool of the consensus node to perform packaging processing so as to obtain a block to be verified, wherein the block is to be broadcasted to the core consensus network layer.

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. The transaction data processing device 1 may be a computer program (including program code) running in a computer apparatus, e.g. 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 apparatus 1 may operate in a first node in the core consensus network, which may be the consensus node 20C in the embodiment corresponding to fig. 2. The transaction data processing device 1 may include: the block writing method includes a packaging processing module 10, a structure information determining module 20, a structure information broadcasting module 30, a consensus result analyzing module 40 and a block writing module 50.

The packaging processing module 10 is configured to obtain initial transaction data forwarded by the proxy node, and package the initial transaction data to obtain a to-be-verified block to be broadcasted to the core consensus network; the initial transaction data is sent by a service node in the service network; the proxy node is used for carrying out network isolation on the service network and the core consensus network.

Wherein, this packing processing module 10 includes: a transaction verification unit 101, a transaction adding unit 102, a transaction hash determination unit 103, and a to-be-verified block generation unit 104.

The transaction verification unit 101 is configured to obtain initial transaction data forwarded by a service node in a service network through a proxy node, and perform transaction verification on the initial transaction data to obtain a transaction verification result.

Wherein the transaction verification unit 101 comprises: an encryption information acquisition sub-unit 1011, a decryption sub-unit 1012, a signature verification sub-unit 1013, and a transaction verification sub-unit 1014.

The encrypted information acquiring subunit 1011 is configured to acquire system encrypted data information sent by the proxy node; the system encryption data information is obtained by the agent node through encrypting the initial transaction data and the signature information through the system public key of the core consensus network; the signature information is obtained after the agent node signs the initial transaction data through the node private key of the agent node when the agent node obtains the initial transaction data sent by the service node in the service network;

the decryption subunit 1012 is configured to decrypt the system encrypted data information through a system private key corresponding to the system public key to obtain initial transaction data and signature information;

the signature verification subunit 1013 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 transaction verification subunit 1014 is configured to perform transaction verification on the initial transaction data when the signature verification result indicates that the signature verification is successful, and determine a transaction verification result of the initial transaction data.

For specific implementation manners of the encrypted information obtaining sub-unit 1011, the decrypting sub-unit 1012, the signature verifying sub-unit 1013, and the transaction verifying sub-unit 1014, reference may be made to the description of the initial transaction data in the embodiment corresponding to fig. 4, and details will not be further described here.

The transaction adding unit 102 is configured to add initial transaction data to a first transaction pool of the first node when the transaction verification result indicates that the transaction verification is successful, obtain a transaction data set including the initial transaction data from the first transaction pool, and use the transaction data in the transaction data set as transaction data to be processed;

the transaction hash determining unit 103 is configured to perform transaction hash conversion on transaction data to be processed to obtain a transaction hash value corresponding to the transaction data to be processed, and determine a root of a mercker tree corresponding to the transaction data to be processed based on the transaction hash value;

the to-be-verified block generating unit 104 is configured to acquire a first block with a maximum generation timestamp from a target block chain of the core consensus network, use a block hash value of the first block as a parent block hash value of a next block of the first block, generate the next block of the first block based on the to-be-processed transaction data, the mercker tree root, and the parent block hash value, and use the generated next block of the first block as a to-be-verified block to be written into the target block chain; the generation timestamp of the to-be-verified block is used to update the maximum generation timestamp on the target blockchain.

For specific implementation manners of the transaction verification unit 101, the transaction adding unit 102, the transaction hash determination unit 103, and the to-be-verified block generation unit 104, 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 structure information determining module 20 is configured to obtain a second node from the core consensus network, and obtain first structure information of a dense block corresponding to the block to be verified based on the predicted prediction auxiliary information of the second node and the block information of the block to be verified; the first structure information comprises a target transaction identifier corresponding to the initial transaction data; the target transaction identifier is determined after a hash identification transformation of the initial transaction data.

the configuration information determination module 20 includes: a list acquisition unit 201, a node determination unit 202, a predicted transaction determination unit 203, a target transaction identification determination unit 204, and a structure information generation unit 205.

The list acquiring unit 201 is configured to acquire a first list and a second list maintained by a first node at a first time; the first list comprises first node identifications of nodes having a network connection relationship with the first node at a first time; the second list comprises second node identifications of nodes accessing the core consensus network at the first moment;

the node determining unit 202 is configured to determine a node identifier list maintained by the first node at the second time based on a first node identifier in the first list and a second node identifier in the second list, and determine a second node to be broadcasted from the node identifier list; the second moment is the next moment of the first moment;

the predicted transaction determining unit 203 is configured to acquire a network switching state of the second node from a first time to a second time, determine, based on the network switching state, prediction auxiliary information of the second node, and determine, based on the prediction auxiliary information, predicted transaction data for sending to the second node from the transaction data to be processed;

the target transaction identifier determining unit 204 is configured to, in the to-be-processed transaction data, use the transaction data except the predicted transaction data as target transaction data, and perform hash identifier conversion on the target transaction data based on an identifier determination rule to obtain a target transaction identifier corresponding to the target transaction data.

The target transaction identification determination unit 204 includes: a target transaction determining sub-unit 2041, an identification rule obtaining sub-unit 2042, a first hash conversion sub-unit 2043, and a second hash conversion sub-unit 2044.

The target transaction determining subunit 2041 is configured to, in the to-be-processed transaction data, use transaction data other than the predicted transaction data as target transaction data;

the identification rule obtaining sub-unit 2042 is configured to obtain an identifier determination rule including a first hash rule and a second hash rule; the first hash rule is different from the second hash rule;

the first hash conversion subunit 2043 is configured to perform a first hash conversion on the target transaction data based on a first hash rule, so as to obtain a first hash value corresponding to the target transaction data;

the second hash conversion sub-unit 2044 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 target transaction data, and obtain a target transaction identifier corresponding to the target transaction data based on the second hash value and the number of hash bytes associated with the second hash rule.

For specific implementation manners of the target transaction determining sub-unit 2041, the identification rule obtaining sub-unit 2042, the first hash conversion sub-unit 2043, and the second hash conversion sub-unit 2044, reference may be made to the description of the target transaction identifier in the embodiment corresponding to fig. 3, which will not be described again here.

The structure information generating unit 205 is configured to generate first structure information of a dense block corresponding to the block to be verified, based on the block header information, the predicted transaction data, and the target transaction identifier in the block information.

For specific implementation manners of the list obtaining unit 201, the node determining unit 202, the predicted transaction determining unit 203, the target transaction identifier determining unit 204, and the structure information generating unit 205, 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 structure information broadcasting module 30 is configured to broadcast the first structure information to the second node, so that the second node recognizes the to-be-verified block based on the target transaction identifier.

the consensus result analysis module 40 is configured to, when receiving a first consensus result returned by the third node and a second consensus result returned by the second node, perform result analysis on the target consensus result by using the first consensus result and the second consensus result as target consensus results;

the block writing module 50 is configured to determine that the consensus on the block to be verified is achieved and write the block to be verified into the target block chain of the core consensus network if it is determined that the target consensus result exceeding the consensus threshold indicates successful consensus among the target consensus results.

For specific implementation manners of the packaging processing module 10, the structural information determining module 20, the structural information broadcasting module 30, the consensus result analyzing module 40, and the block writing module 50, reference may be made to the description of step S101 to step S103 in the embodiment corresponding to fig. 3, and details will not be further described 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 structural diagram of a transaction data processing apparatus according to an embodiment of the present application. The transaction data processing device 2 may be a computer program (including program code) running on a computer apparatus, e.g. the transaction data processing device 2 is an application software; the transaction data processing device 2 may be configured to perform corresponding steps in the method provided by the embodiment of the present application. As shown in fig. 11, the transaction data processing device 2 may operate in a second node of the core consensus network, which may be the consensus node 20D in the embodiment corresponding to fig. 2. The transaction data processing device 2 may include: a configuration information receiving module 60 and a consensus module 70.

The structure information receiving module 60 is configured to receive first structure information of a dense block corresponding to a block to be verified, where the first structure information is sent by a first node in a core consensus network; the block to be verified is obtained by packaging the initial transaction data by the first node; the initial transaction data is forwarded by the service node in the service network through the proxy node; the agent node is used for carrying out network isolation on the service network and the core consensus network; the first structure information is determined by the first node based on the predicted prediction assistance information of the second node and the block information of the block to be verified.

Wherein, the structure information receiving module 60 includes: a connection notification sending unit 601, a block header searching unit 602, a block acquisition request sending unit 603, and a structure information receiving unit 604.

The connection notification sending unit 601 is configured to send a connection notification to a first node in the core consensus network based on the tight block connection mode, so that the first node uses block header information of a block to be verified as block header information to be confirmed; the connection notification is used for indicating that a compact block connection mode is adopted between the first node and the second node for data transmission;

the block header searching unit 602 is configured to receive block header information to be confirmed returned by the first node, and search, in a node memory of the second node, historical block header information matched with the block header information to be confirmed;

the block obtaining request sending unit 603 is configured to send a block obtaining request to the first node if the historical block header information matching the block header information to be confirmed is not found; the block acquisition request is used for indicating a first node to determine first structure information of a compact block corresponding to a block to be verified based on a compact block connection mode;

the configuration information receiving unit 604 is configured to receive the first configuration information sent by the first node.

For specific implementation manners of the connection notification sending unit 601, the block header searching unit 602, the block obtaining request sending unit 603, and the structure information receiving unit 604, reference may be made to the description of step S204 to step S205 in the embodiment corresponding to fig. 7, and details will not be further described here.

The consensus module 70 is configured to obtain a target transaction identifier from the first structure information, and perform consensus on the to-be-verified blocks based on the target transaction identifier; the target transaction identifier is determined by the first node after hash identification conversion of the initial transaction data.

the consensus module 70 comprises: a target transaction identifier obtaining unit 701, a local transaction identifier determining unit 702, an identifier comparing unit 703 and a consensus unit 704.

The target transaction identifier obtaining unit 701 is configured to obtain a target transaction identifier from the first structure information; the target transaction identifier is determined by the first node after performing hash identification conversion on target transaction data in the transaction data to be processed based on the identifier determination rule; the target transaction data is transaction data except the predicted transaction data in the transaction data to be processed; the predicted transaction data is the transaction data determined by the first node based on the prediction auxiliary information in the transaction data to be processed;

the local transaction identifier determining unit 702 is configured to perform hash identifier conversion on local transaction data in a second transaction pool of a second node based on an identifier determining rule, so as to obtain a local transaction identifier corresponding to the local transaction data;

the identifier comparing unit 703 is configured to compare the local transaction identifier with the target transaction identifier to obtain a comparison result, and obtain key transaction data for reconstructing the to-be-verified block based on the comparison result.

The identifier comparing unit 703 includes: an identification ratio sub-unit 7031, a transaction synchronization request generation sub-unit 7032 and a critical transaction determination sub-unit 7033.

The identifier comparison subunit 7031 is configured to compare the local transaction identifier with the target transaction identifier to obtain a comparison result;

the transaction synchronization request generating subunit 7032 is configured to, if the comparison result indicates that the target transaction identifier is different from the local transaction identifier, generate, based on the target transaction identifier, a transaction synchronization request for sending to the first node, so that the first node obtains, based on the transaction synchronization request, target transaction data corresponding to the target transaction identifier from the to-be-processed transaction data in the block information;

the key transaction determining subunit 7033 is configured to, when receiving the target transaction data returned by the first node, use the target transaction data as key transaction data for reconstructing the to-be-verified block.

For specific implementation manners of the identifier ratio sub-unit 7031, the transaction synchronization request generation sub-unit 7032, and the key transaction determination sub-unit 7033, reference may be made to the description of the key transaction data in the embodiment corresponding to fig. 7, which will not be described again here.

The consensus unit 704 is configured to perform consensus on the to-be-verified block based on the key transaction data and the first structure information.

the consensus unit 704 comprises: a restructuring subunit 7041, a to-be-compared tree root determining subunit 7042, and a consensus subunit 7043.

The reconstructing subunit 7041 is configured to reconstruct to obtain a to-be-verified block based on the key transaction data, the block header information, and the predicted transaction data;

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

the consensus subunit 7043 is configured to compare the root of the mercker tree in the block header information with the root of the tree to be compared, and perform consensus on the block to be verified according to the comparison result.

For a specific implementation manner of the restructuring subunit 7041, the to-be-compared tree root determining subunit 7042, and the consensus subunit 7043, reference may be made to the description of consensus on the to-be-verified blocks in the embodiment corresponding to fig. 7, which will not be further described here.

For specific implementation manners of the target transaction identifier obtaining unit 701, the local transaction identifier determining unit 702, the identifier comparing unit 703 and the consensus unit 704, reference may be made to the description of step S206 in the embodiment corresponding to fig. 7, and details will not be further described here.

For specific implementation of the structure information receiving module 60 and the consensus module 70, reference may be made to the description of step S201 to step S206 in the embodiment corresponding to fig. 7, which will not be further described herein. In addition, the beneficial effects of the same method are not described in detail.

Further, please refer to fig. 12, fig. 12 is a schematic diagram of a computer device according to an embodiment of the present application. As shown in fig. 12, the computer device 3000 may include: at least one processor 3001, e.g., a CPU, at least one network interface 3004, a user interface 3003, memory 3005, at least one communication bus 3002. The communication bus 3002 is used to realize connection communication between these components. The user interface 3003 may include a Display screen (Display) and a Keyboard (Keyboard), and the network interface 3004 may optionally include a standard wired interface and a wireless interface (e.g., WI-FI interface). The memory 3005 may be a high-speed RAM memory or a non-volatile memory (e.g., at least one disk memory). The storage 3005 may optionally also be at least one storage device located remotely from the aforementioned processor 3001. As shown in fig. 12, the memory 3005, which is one type 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 3000 shown in fig. 12, the network interface 3004 is mainly used for performing network communication; and the user interface 3003 is an interface mainly for providing input to the user; and the processor 3001 may be used to invoke device control applications stored in the memory 3005.

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

Further, here, it is to be noted that: an embodiment of the present application further provides a computer-readable storage medium, where a computer program executed by the aforementioned transaction data processing apparatus 1 or transaction data processing apparatus 2 is stored in the computer-readable storage medium, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the transaction data processing method in the embodiment corresponding to fig. 3 or fig. 7 can be executed, and therefore, details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of embodiments of the method of the present application. As an example, program instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network, which may comprise a block chain system.

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.

Further, please refer to fig. 13, where fig. 13 is a schematic structural diagram of a data processing system according to an embodiment of the present application. The data processing system 3 may comprise a data processing device 1a and a data processing device 2 a. The data processing apparatus 1a may be the transaction data processing apparatus 1 in the embodiment corresponding to fig. 10, and it is understood that the data processing apparatus 1a may be integrated in the common node 20C in the embodiment corresponding to fig. 2, and therefore, the description thereof will not be repeated here. The data processing device 2a may be the transaction data processing device 2 in the embodiment corresponding to fig. 11, and it is understood that the data processing device 2a may be integrated in the consensus node 20D in the embodiment corresponding to fig. 2, and therefore, the description thereof will not be repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in the embodiments of the data processing system to which the present application relates, reference is made to the description of the embodiments of the method of the present application.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

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 transaction data processing method, performed by a first node in a core consensus network, the method comprising:

acquiring initial transaction data forwarded by a proxy node, and packaging the initial transaction data to obtain a to-be-verified block to be broadcasted to the core consensus network; the initial transaction data is sent by a service node in a service network; the proxy node is used for carrying out network isolation on the service network and the core consensus network; the proxy node belongs to a routing proxy layer; the routing agent layer is a network layer independent of the service network and the core consensus network;

acquiring a second node from the core consensus network, and obtaining first structure information of a compact block corresponding to the block to be verified based on the predicted auxiliary information of the second node and the block information of the block to be verified; the first structure information comprises a target transaction identifier, predicted transaction data and block header information in the block information; the predicted transaction data is determined from pending transaction data of the block information based on the prediction assistance information; the target transaction identifier is determined after hash identification conversion is carried out on target transaction data; the target transaction data is transaction data except the predicted transaction data in the to-be-processed transaction data;

broadcasting the first structure information to the second node so that the second node can identify the block to be verified based on the target transaction identifier.

2. The method of claim 1, wherein the obtaining of initial transaction data forwarded by the proxy node and the packing of the initial transaction data to obtain a block to be verified to be broadcasted to the core consensus network comprises:

acquiring initial transaction data forwarded by a service node in a service network through a proxy node, and performing transaction verification on the initial transaction data to obtain a transaction verification result;

when the transaction verification result indicates that the transaction verification is successful, adding the initial transaction data to a first transaction pool of the first node, acquiring a transaction data set containing the initial transaction data from the first transaction pool, and taking the transaction data in the transaction data set as transaction data to be processed;

performing transaction hash conversion on the transaction data to be processed to obtain a transaction hash value corresponding to the transaction data to be processed, and determining a Merck tree root corresponding to the transaction data to be processed based on the transaction hash value;

acquiring a first block with a maximum generation timestamp from a target block chain of the core consensus network, taking a block hash value of the first block as a parent block hash value of a next block of the first block, generating the next block of the first block based on the transaction data to be processed, the Mercker tree root and the parent block hash value, and taking the generated next block of the first block as a block to be verified, wherein the generated block is to be written into the target block chain; and the generation time stamp of the block to be verified is used for updating the maximum generation time stamp on the target block chain.

3. The method of claim 2, wherein the obtaining initial transaction data forwarded by a service node in a service network via a proxy node, and performing transaction verification on the initial transaction data to obtain a transaction verification result comprises:

acquiring system encryption data information sent by a proxy node; the system encrypted data information is obtained by the agent node through encrypting initial transaction data and signature information by a system public key of the core consensus network; the signature information is obtained after the agent node signs the initial transaction data through a node private key of the agent node when the agent node obtains the initial transaction data sent by a service node in a service network;

decrypting the system encrypted data information through a system private key corresponding to the system public key to obtain the initial transaction data 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, performing transaction verification on the initial transaction data, and determining a transaction verification result of the initial transaction data.

4. The method according to claim 1, wherein the block information of the block to be verified includes transaction data to be processed, and the initial transaction data is transaction data in the transaction data to be processed;

the obtaining a second node from the core consensus network, and based on the predicted auxiliary information of the second node and the block information of the block to be verified, obtaining first structure information of a dense block corresponding to the block to be verified, includes:

acquiring a first list and a second list maintained by the first node at a first moment; the first list comprises first node identifications of nodes having network connection relations with the first node at the first time; the second list comprises second node identities of nodes accessing the core consensus network at the first time;

determining a node identification list maintained by the first node at a second moment based on a first node identification in the first list and a second node identification in the second list, and determining a second node to be broadcasted from the node identification list; the second moment is the next moment of the first moment;

acquiring a network switching state of the second node from the first moment to the second moment, determining prediction auxiliary information of the second node based on the network switching state, and determining prediction transaction data for sending to the second node from the to-be-processed transaction data based on the prediction auxiliary information;

in the transaction data to be processed, taking the transaction data except the predicted transaction data as target transaction data, and performing hash identification conversion on the target transaction data based on an identifier determination rule to obtain a target transaction identifier corresponding to the target transaction data;

and generating first structure information of a compact block corresponding to the block to be verified based on block header information in the block information, the predicted transaction data and the target transaction identifier.

5. The method according to claim 4, wherein the step of performing hash identification conversion on the target transaction data based on an identifier determination rule by using the transaction data except the predicted transaction data as the target transaction data in the transaction data to be processed to obtain a target transaction identifier corresponding to the target transaction data comprises:

in the transaction data to be processed, taking transaction data except the predicted transaction data as target transaction data;

acquiring an identifier determination rule comprising a first hash rule and a second hash rule; the first hash rule is different from the second hash rule;

performing first hash conversion on the target transaction data based on the first hash rule to obtain a first hash value corresponding to the target 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 target transaction data, and obtaining a target transaction identifier corresponding to the target transaction data based on the second hash value and the hash byte number associated with the second hash rule.

6. The method of claim 1, wherein a third node is included in the core consensus network; the third node is a node other than the first node and the second node; the third node is used for identifying the to-be-verified blocks when receiving second structure information of the compact blocks corresponding to the to-be-verified blocks;

the method further comprises the following steps:

when a first consensus result returned by the third node and a second consensus result returned by the second node are received, taking the first consensus result and the second consensus result as target consensus results, and performing result analysis on the target consensus results;

and if the target consensus result exceeding the consensus threshold value is determined to exist in the target consensus results to indicate successful consensus, determining that the consensus on the block to be verified is achieved, and writing the block to be verified into a target block chain of the core consensus network.

7. A transaction data processing method, performed by a second node in a core consensus network, the method comprising:

receiving first structure information of a compact block corresponding to a block to be verified, which is sent by a first node in the core consensus network; the block to be verified is obtained by packaging the initial transaction data by the first node; the initial transaction data is forwarded by a service node in a service network through a proxy node; the proxy node is used for carrying out network isolation on the service network and the core consensus network; the proxy node belongs to a routing proxy layer; the routing agent layer is a network layer independent of the service network and the core consensus network; the first structure information is determined by the first node based on predicted prediction assistance information of the second node and block information of the block to be verified; the first structure information comprises a target transaction identifier, predicted transaction data and block header information in the block information; the predicted transaction data is determined from pending transaction data of the block information based on the prediction assistance information; the target transaction identifier is determined after hash identification conversion is carried out on target transaction data; the target transaction data is transaction data except the predicted transaction data in the to-be-processed transaction data;

and acquiring the target transaction identifier from the first structure information, and identifying the to-be-verified block based on the target transaction identifier.

8. The method of claim 7, wherein the receiving first structure information of the compact block corresponding to the block to be verified sent by the first node in the core consensus network comprises:

sending a connection notification to a first node in the core consensus network based on a compact block connection mode so that the first node takes block header information of the block to be verified as block header information to be confirmed; the connection notification is used for indicating the first node and the second node to adopt the compact block connection mode for data transmission;

receiving the block head information to be confirmed returned by the first node, and searching historical block head information matched with the block head information to be confirmed in a node memory of the second node;

if the historical block header information matched with the block header information to be confirmed is not found, sending a block acquisition request to the first node; the block acquisition request is used for indicating the first node to determine first structure information of a compact block corresponding to the block to be verified based on the compact block connection mode;

and receiving the first structure information sent by the first node.

9. The method of claim 7, wherein the block information comprises pending transaction data and the initial transaction data is transaction data in the pending transaction data;

the obtaining a target transaction identifier from the first structure information, and identifying the to-be-verified block based on the target transaction identifier includes:

obtaining a target transaction identifier from the first structure information; the target transaction identifier is determined by the first node after performing hash identification conversion on target transaction data in the to-be-processed transaction data based on an identifier determination rule; the target transaction data is transaction data except predicted transaction data in the to-be-processed transaction data; the predicted transaction data is determined by the first node based on the prediction auxiliary information in the to-be-processed transaction data;

based on the identifier determination rule, performing hash identification conversion on local transaction data in a second transaction pool of the second node to obtain a local transaction identifier corresponding to the local transaction data;

comparing the local transaction identifier with the target transaction identifier to obtain a comparison result, and acquiring key transaction data for reconstructing the to-be-verified block based on the comparison result;

and on the basis of the key transaction data and the first structure information, performing consensus on the to-be-verified block.

10. The method according to claim 9, wherein the comparing the local transaction identifier with the target transaction identifier to obtain a comparison result, and acquiring key transaction data for reconstructing the block to be verified based on the comparison result comprises:

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

if the comparison result indicates that the target transaction identifier is different from the local transaction identifier, generating a transaction synchronization request for sending to the first node based on the target transaction identifier, so that the first node obtains target transaction data corresponding to the target transaction identifier from the to-be-processed transaction data in the block information based on the transaction synchronization request;

and when target transaction data returned by the first node are received, the target transaction data are used as key transaction data for reconstructing the to-be-verified block.

11. The method of claim 9, wherein the first structure information comprises block header information of the block to be verified and the predicted transaction data;

the consensus on the to-be-verified block based on the key transaction data and the first structure information includes:

reconstructing to obtain the to-be-verified block based on the key transaction data, the block header information and the predicted transaction data;

acquiring a Mercker path associated with the key transaction data, acquiring a key transaction hash value corresponding to the 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 verified;

and comparing the Merck tree root in the block header information with the tree root to be compared, and identifying the block to be verified according to the comparison result.

12. A transaction data processing apparatus, comprising:

the system comprises a packaging processing module, a core consensus network and a verification processing module, wherein the packaging processing module is used for acquiring initial transaction data forwarded by a proxy node, and packaging the initial transaction data to obtain a to-be-verified block to be broadcasted to the core consensus network; the initial transaction data is sent by a service node in a service network; the proxy node is used for carrying out network isolation on the service network and the core consensus network; the proxy node belongs to a routing proxy layer; the routing agent layer is a network layer independent of the service network and the core consensus network;

the structure information determining module is used for acquiring a second node from the core consensus network, and obtaining first structure information of a compact block corresponding to the block to be verified based on the predicted auxiliary information of the second node and the block information of the block to be verified; the first structure information comprises a target transaction identifier, predicted transaction data and block header information in the block information; the predicted transaction data is determined from pending transaction data of the block information based on the prediction assistance information; the target transaction identifier is determined after hash identification conversion is carried out on target transaction data; the target transaction data is transaction data except the predicted transaction data in the to-be-processed transaction data;

a structure information broadcasting module, configured to broadcast the first structure information to the second node, so that the second node recognizes the to-be-verified block based on the target transaction identifier.

13. A transaction data processing apparatus, comprising:

the structure information receiving module is used for receiving first structure information of a compact block corresponding to a block to be verified, which is sent by a first node in the core consensus network; the block to be verified is obtained by packaging the initial transaction data by the first node; the initial transaction data is forwarded by a service node in a service network through a proxy node; the proxy node is used for carrying out network isolation on the service network and the core consensus network; the proxy node belongs to a routing proxy layer; the routing agent layer is a network layer independent of the service network and the core consensus network; the first structure information is determined by the first node based on predicted prediction auxiliary information of the second node and block information of the block to be verified; the first structure information comprises a target transaction identifier, predicted transaction data and block header information in the block information; the predicted transaction data is determined from pending transaction data of the block information based on the prediction assistance information; the target transaction identifier is determined after hash identification conversion is carried out on target transaction data; the target transaction data is transaction data except the predicted transaction data in the to-be-processed transaction data;

and the consensus module is used for acquiring the target transaction identifier from the first structure information and performing consensus on the to-be-verified blocks based on the target transaction identifier.

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

the processor is connected to a memory for storing a computer program, the processor being configured to invoke the computer program to cause the computer device to perform the method of any of claims 1-11.

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 11.