CN113259130B - Transaction data processing method, device, equipment and medium - Google Patents

Transaction data processing method, device, equipment and medium Download PDF

Info

Publication number
CN113259130B
CN113259130B CN202110688386.XA CN202110688386A CN113259130B CN 113259130 B CN113259130 B CN 113259130B CN 202110688386 A CN202110688386 A CN 202110688386A CN 113259130 B CN113259130 B CN 113259130B
Authority
CN
China
Prior art keywords
block
node
exclusive
data
service node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110688386.XA
Other languages
Chinese (zh)
Other versions
CN113259130A (en
Inventor
朱耿良
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202110688386.XA priority Critical patent/CN113259130B/en
Priority to CN202111088871.XA priority patent/CN113765675B/en
Publication of CN113259130A publication Critical patent/CN113259130A/en
Application granted granted Critical
Publication of CN113259130B publication Critical patent/CN113259130B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Abstract

The embodiment of the application provides a transaction data processing method, a device, equipment and a medium, wherein the method comprises the following steps: receiving a data clearing request forwarded by a first service node in a service network through a proxy node; based on the data sorting request, acquiring a block to be processed in the descending direction of the block heights of (N-M) blocks from the block height M to the block height N on the block chain, and performing block identification on the block to be processed to obtain a block identification result; if the block identification result indicates that the block to be processed is the first exclusive block, acquiring block anchoring information in the first exclusive block, and positioning to an anchoring positioning block in the (N-M) blocks through the block anchoring information; and determining first clearing data for returning to the first service node based on the block type of the anchoring positioning block, and returning the first clearing data to the first service node through the proxy node. By the adoption of the method and the device, privacy isolation of transaction data can be achieved, and data clearing efficiency is improved.

Description

Transaction data processing method, device, equipment and 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 medium for processing transaction data.
Background
The blockchain nodes in the blockchain network can broadcast transaction data generated by executing transaction services to the core consensus network, so that the consensus nodes in the core consensus network can uplink the transaction data. For example, a blockchain node (e.g., node a) may broadcast transaction data generated by performing a transaction service to a consensus node (e.g., node B) to cause node B to write a block including the transaction data associated with node a into the blockchain.
It is understood that when node a in the blockchain network needs to request data liquidation (e.g., block synchronization, transaction query), a data liquidation request may be sent to a consensus node (e.g., node B described above) participating in consensus in the blockchain network. At this time, the node B may determine one or more blocks to be processed in the blockchain of the blockchain network (for example, the number of the blocks to be processed is a plurality of blocks), and further indiscriminately separate the transaction data associated with the node a in each block to be processed, since each block in the blocks to be processed needs to be separated, when there is a block irrelevant to the node a in the blocks to be processed, the privacy security of a large amount of transaction data in the blocks irrelevant to the node a will be affected. In addition, since the node B will indifferently perform the clearing of the transaction data in the blocks unrelated to the node a, the search time of the transaction data related to the node a will be increased, and the efficiency of data clearing will be further reduced.
Disclosure of Invention
The embodiment of the application provides a transaction data processing method, a device, equipment and a medium, which can realize privacy isolation of transaction data and improve data clearing efficiency.
In one aspect, an embodiment of the present invention provides a transaction data processing method, which is performed by a consensus node in a core consensus network, and includes:
receiving a data clearing request forwarded by a first service node in a service network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request carries a block height M and a block height N; the block height M is the maximum block height on the block head chain stored by the first service node; the block height N is the maximum block height on the block chain maintained by the common node; n is a positive integer; m is a positive integer less than N;
determining (N-M) blocks from the block height M to the block height N on a block chain based on the data sorting request, acquiring a block to be processed in the descending direction of the block height of the (N-M) blocks, and performing block identification on the block to be processed to obtain a block identification result;
if the block identification result indicates that the block to be processed is a first type of exclusive block associated with the first service node, acquiring block anchoring information in the first type of exclusive block, positioning the block associated with the first service node in the (N-M) blocks through the block anchoring information, and determining the positioned block as an anchoring positioning block; the block height of the anchoring positioning block is smaller than that of the block to be processed, and the block between the anchoring positioning block and the block to be processed is a block which is skipped based on the block anchoring information and is irrelevant to the first service node;
and determining first clearing data for returning to the first service node based on the block type of the anchoring positioning block, and returning the first clearing data to the first service node through the proxy node.
An aspect of an embodiment of the present application provides a transaction data processing apparatus, including:
the request receiving module is used for receiving a data clearing request forwarded by a first service node in a service network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request carries a block height M and a block height N; the block height M is the maximum block height on the block head chain stored by the first service node; the block height N is the maximum block height on the block chain maintained by the common node; n is a positive integer; m is a positive integer less than N;
the block acquisition module is used for determining (N-M) blocks from the block height M to the block height N on a block chain based on the data sorting request, acquiring a block to be processed in the descending direction of the block heights of the (N-M) blocks, and performing block identification on the block to be processed to obtain a block identification result;
a block positioning module, configured to, if the block identification result indicates that the block to be processed is a first type of exclusive block associated with the first service node, obtain block anchor information in the first type of exclusive block, position the block associated with the first service node among the (N-M) blocks through the block anchor information, and determine the positioned block as an anchor positioning block; the block height of the anchoring positioning block is smaller than that of the block to be processed, and the block between the anchoring positioning block and the block to be processed is a block which is skipped based on the block anchoring information and is irrelevant to the first service node;
and the first returning module is used for determining first clearing data for returning to the first service node based on the block type of the anchoring positioning block and returning the first clearing data to the first service node through the proxy node.
Wherein, the block acquisition module includes:
the block determining unit is used for determining (N-M) blocks from a block height M to a block height N on a block chain based on the data sorting request, and marking the block identification states of the determined (N-M) blocks as to-be-identified states;
a block identification unit for identifying, among the (N-M) blocks, a block that identifies a state to be identified and has a maximum block height as a block to be processed, the block identification information in the block to be processed;
the first identification unit is used for taking the block type of the block to be processed as the first block type when the block identification information is identified as the first type of block identification information, marking the block identification state of the block to be processed with the first block type as an identified state from the to-be-identified state, taking the block to be processed with the first block type and the identified state as an exclusive block to be classified, and acquiring node identification information in the exclusive block to be classified;
a first adding unit, configured to determine, if the obtained node identification information is a first class node identification associated with the first service node, the exclusive block to be classified as a first class exclusive block associated with the first service node, take the first class exclusive block as a first exclusive identification result, and add the first exclusive identification result to the block identification result corresponding to the block to be processed; the first exclusive identification result is used for executing the step of acquiring the block anchoring information in the first type exclusive block when the block to be processed is the first type exclusive block.
Wherein the service network comprises a second service node;
the block acquisition module further comprises:
and the second adding unit is used for determining the exclusive block to be classified as a second exclusive block irrelevant to the first service node if the acquired node identification information is a second node identification associated with the second service node, taking the second exclusive block as a second exclusive recognition result, and adding the second exclusive recognition result to the block recognition result corresponding to the block to be processed.
Wherein, the device still includes:
the data hiding module is used for hiding data of the second exclusive block based on the second exclusive block indicated by the second exclusive identification result if the block identification result comprises the second exclusive identification result, so as to obtain a block hash of the second exclusive block and a parent block hash of the second exclusive block;
and the second returning module is used for taking the block hash of the second exclusive block and the parent block hash of the second exclusive block as second clearing data of the first service node and returning the second clearing data to the first service node through the proxy node.
Wherein, the block acquisition module further comprises:
the second identification unit is used for taking the block type of the block to be processed as the second block type when the block identification information is identified as the second type of block identification information, marking the block identification state of the block to be processed with the second block type as an identified state from the to-be-identified state, taking the block to be processed with the second block type and the identified state as a non-exclusive block to be classified, and screening the transaction data associated with the first service node in the non-exclusive block to be classified;
and the third adding unit is used for determining the non-exclusive blocks to be classified as first non-exclusive blocks associated with the first service node if the transaction data associated with the first service node is screened from the non-exclusive blocks to be classified, taking the first non-exclusive blocks as first non-exclusive identification results, and adding the first non-exclusive identification results to the block identification results corresponding to the blocks to be processed.
Wherein, the device still includes:
the transaction determining module is used for taking transaction data associated with the first service node in the first non-exclusive block as first transaction data based on the first non-exclusive block indicated by the first non-exclusive identification result if the block identification result comprises the first non-exclusive identification result;
and the third returning module is used for acquiring the block head of the first non-exclusive block and first Mercker certification information corresponding to the first transaction data, taking the first transaction data, the first Mercker certification information and the block head of the first non-exclusive block as third clearing data of the first service node, and returning the third clearing data to the first service node through the proxy node.
Wherein, the block acquisition module further comprises:
and the fourth adding unit is used for determining the non-exclusive blocks to be classified as second non-exclusive blocks irrelevant to the first service node if the transaction data relevant to the first service node is not screened from the non-exclusive blocks to be classified, taking the second non-exclusive blocks as second non-exclusive identification results, and adding the second non-exclusive identification results to the block identification results corresponding to the blocks to be processed.
Wherein, the device still includes:
and the fourth returning module is used for taking the block head of the second non-exclusive block as fourth clearing data of the first service node and returning the fourth clearing data to the first service node through the proxy node based on the second non-exclusive block indicated by the second non-exclusive identification result if the block identification result comprises the second non-exclusive identification result.
Wherein the first return module comprises:
a first comparing unit, configured to use the anchor positioning block as first sub-clearing data of the first service node if the block type of the anchor positioning block is the same as the block type of the first exclusive block;
a second comparing unit, configured to, if the block type of the anchor positioning block is different from the block type of the first exclusive block, obtain key service data information associated with the first service node in the anchor positioning block, and use the obtained key service data information as second sub-liquidation data of the first service node;
and the data returning unit is used for taking the first sub-liquidation data or the second sub-liquidation data as the first liquidation data of the first service node and returning the first liquidation data to the first service node through the proxy node.
Wherein, the device still includes:
the first determining module is used for taking the first exclusive block as fifth clearing data of the first service node;
a second determining module, configured to determine, among the (N-M) blocks, sixth credit data for returning to the first service node based on a block type of a service filter block, using a block between the anchor positioning block and the first type exclusive block as a service filter block unrelated to the first service node;
and the data returning module is used for returning the fifth clearing data and the sixth clearing data to the first service node through the proxy node.
In one aspect, an embodiment of the present application provides a transaction data processing method, which is executed by a first service node in a service network, and includes:
acquiring a block height M and a block height N, and generating a data clearing request based on the block height M and the block height N; the block height M is the maximum block height on the block head chain stored by the first service node; the block height N is the maximum block height on a block chain maintained by a consensus node in the core consensus network; n is a positive integer; m is a positive integer less than N;
sending a data clearing request to a consensus node through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request is used for indicating the consensus node to acquire the block to be processed in the descending direction of the block heights of the (N-M) blocks from the block height M to the block height N of the block chain, and performing block identification on the block to be processed to obtain a block identification result;
receiving first clearing data returned by the consensus node through the proxy node; the first liquidity data is determined by the consensus node based on the block type of the anchor positioning block; the anchor positioning block is positioned in the (N-M) blocks by the common node through the block anchor information; the block anchoring information is obtained after the consensus node determines that the block identification result indicates that the block to be processed is a first exclusive block associated with the first service node; the block height of the anchor positioning block is smaller than the block height of the block to be processed, and the block between the anchor positioning block and the block to be processed is a block that is skipped based on the block anchor information and is unrelated to the first service node.
An aspect of an embodiment of the present application provides a transaction data processing apparatus, including:
the request generation module is used for acquiring the block height M and the block height N and generating a data clearing request based on the block height M and the block height N; the block height M is the maximum block height on the block head chain stored by the first service node; the block height N is the maximum block height on a block chain maintained by a consensus node in the core consensus network; n is a positive integer; m is a positive integer less than N;
the request sending module is used for sending a data clearing request to the consensus node through the agent node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request is used for indicating the consensus node to acquire the block to be processed in the descending direction of the block heights of the (N-M) blocks from the block height M to the block height N of the block chain, and performing block identification on the block to be processed to obtain a block identification result;
the data receiving module is used for receiving first clearing data returned by the consensus node through the agent node; the first liquidity data is determined by the consensus node based on the block type of the anchor positioning block; the anchor positioning block is positioned in the (N-M) blocks by the common node through the block anchor information; the block anchoring information is obtained after the consensus node determines that the block identification result indicates that the block to be processed is a first exclusive block associated with the first service node; the block height of the anchor positioning block is smaller than the block height of the block to be processed, and the block between the anchor positioning block and the block to be processed is a block that is skipped based on the block anchor information and is unrelated to the first service node.
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 this embodiment of the application, when receiving a data sorting request forwarded by a first service node in a service network through a proxy node for performing network isolation on the core consensus network and the service network, a consensus node in the core consensus network may determine (N-M) blocks from a block height M to the block height N on a block chain based on a block height M and a block height N carried in the data sorting request, further obtain a block to be processed in a direction of decreasing block heights of the (N-M) blocks, and perform block identification on the block to be processed, thereby obtaining a block identification result. Here, the block height M may be a maximum block height on a block head chain stored in the first service node, and the block height N may be a maximum block height on a block chain maintained by the common node. Where N may be a positive integer, and where M may be a positive integer less than N. Further, if the block identification result indicates that the block to be processed is a first type of exclusive block associated with the first service node, the common node may obtain block anchor information in the first type of exclusive block, locate, from among the (N-M) blocks, the block associated with the first service node by using the block anchor information, and determine the located block as an anchor located block. The block height of the anchor positioning block is smaller than that of the block to be processed, and the block between the anchor positioning block and the block to be processed is a block which is skipped based on the block anchor information and is irrelevant to the first service node. Further, the consensus node may determine first clearing data for returning to the first service node based on the block type of the anchor positioning block, and return the first clearing data to the first service node through the proxy node. Therefore, the embodiment of the application can realize the function of the network node in the hierarchical block chain structure of the service network-core consensus network, performing block identification on the to-be-processed blocks sequentially acquired from the (N-M) blocks, so as to anchor information by the blocks in the first type exclusive blocks when the acquired to-be-processed blocks are determined to be the first type exclusive blocks, based on the fast positioning of the anchor positioning block associated with the first exclusive block in the (N-M) blocks, when the liquidation data (e.g., the first liquidation data) corresponding to the data liquidation request is returned for the first service node, the embodiments of the present application may fast skip the blocks unrelated to the first service node by the block anchor information, and meanwhile, the data is cleared to the anchoring positioning block associated with the first service node, so that the data clearing efficiency can be improved. Furthermore, for those skipped blocks that are not associated with the first service node, the transaction data within those blocks are not returned as credit data to the first service node in the service network, and thus privacy isolation of the transaction data within those skipped blocks can be achieved.
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 view of a scenario for sending a data credit request according to an embodiment of the present application;
FIG. 5 is a schematic flow chart of determining score data according to an embodiment of the present application;
fig. 6 is a schematic view of a scenario for hiding 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 view of a scenario in which a data credit request is received according to an embodiment of the present application;
fig. 9a is a schematic view of a scenario for locating an exclusive block according to an embodiment of the present application;
fig. 9b is a schematic view of a scenario for locating a normal block according to an embodiment of the present application;
fig. 10 is a system architecture diagram in a block chain electronic bill scenario 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 structural diagram of a transaction data processing device according to an embodiment of the present application;
fig. 13 is a schematic structural diagram of a computer device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Specifically, please refer to fig. 1, in which 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 100 b), a first blockchain system, and a second blockchain system, to form the blockchain network 2000 shown in fig. 1. The first and second blockchain systems may each include one or more nodes, and the number of nodes in the first and second blockchain systems is not limited herein. As shown in fig. 1, the first blockchain system may specifically include a node 110a, a node 110b, nodes 110c, …, 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) 100a, and nodes in the service network 100a may be referred to as service nodes, where the service nodes are mainly used for performing 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. In order to ensure the information intercommunication in the first blockchain system, information connection may exist between each node in the first blockchain system, and information transmission may be performed between the nodes through the information connection.
The blockchain network corresponding to the second blockchain system may be referred to as a core consensus network (i.e., a consensus network) 100c, and a node in the core consensus network 100c may be referred to as a consensus node (i.e., an accounting node), where the consensus node may operate with a blockchain consensus protocol. In order to ensure the information intercommunication in the second blockchain system, information connection may exist between each node in the second blockchain system, and information transmission may be performed between the nodes through the information connection.
It is to be understood that the information connection in the first blockchain system and the second blockchain system is not limited to the connection manner, and may be directly or indirectly connected through a wired communication manner, may also be directly or indirectly connected through a wireless communication manner, and may also be connected through other connection manners, which is not limited herein.
The proxy node 100b shown in fig. 1 may be configured To perform network isolation on the service network 100a and the core consensus network 100c, and the proxy node 100b may perform network layering on a Peer-To-Peer (Peer To Peer, abbreviated as P2P) network To form a layered structure (i.e., a two-layer link structure) such as a "service network-core consensus network", so as To improve confidentiality and security of data on a block link.
It is to be understood that, in the embodiment of the present application, the proxy node 100b, the service node in the service network 100a, and the consensus node in the core consensus network 100c may be collectively referred to as a blockchain node in the blockchain network 2000. It is understood that the blockchain node may be a server accessing the blockchain network 2000, or a user terminal accessing the blockchain network 2000, and the specific form of the blockchain node is not limited herein. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as cloud service, a cloud database, cloud computing, a cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN, big data and artificial intelligence platform. The user terminal may be a mobile phone, a tablet computer, a notebook computer, a palm computer, an intelligent sound, a mobile internet device (MID, a mobile internet device), a POS (Point Of Sales) machine, a wearable device (e.g., an intelligent watch, an intelligent bracelet, etc.), and the like.
It is to be understood that some nodes in the blockchain network 2000 shown in fig. 1 store a complete blockchain database, and such nodes containing all transaction data may be referred to as Full nodes (Full nodes, e.g., consensus nodes shown in fig. 1); other nodes store part of the blockchain database, typically only store the block header and transaction data associated with their own Node, but not store complete transaction data, and they perform transaction checking in a Simplified transaction Verification (SPV) manner, such nodes may be referred to as Lightweight nodes (Lightweight nodes) or SPV nodes (e.g., service nodes shown in fig. 1).
It is understood that the service network 100a and the core consensus network 100c shown in fig. 1 may be in different network environments, and in general, the service network 100a may be in a public network and the core consensus network 100c may be in a private network. Therefore, the service node is deployed in the service network 100a in the public network (i.e., public network), and the consensus node is deployed in the core consensus network 100c in the private network (i.e., private network), which may interact with each other through the routing boundary.
For convenience of understanding, in the embodiment of the present application, one node may be selected from the plurality of nodes in the service network 110a shown in fig. 1 as a first service node for performing data liquidation, and the first service node has a function of sending a data liquidation request to the proxy node 100b, for example, the embodiment of the present application may use the node 110a shown in fig. 1 as the first service node. It is understood that, in the embodiment of the present application, a node other than the first service node may also be used as the second service node in the plurality of nodes in the service network 110a shown in fig. 1, for example, the embodiment of the present application may use the node 110b shown in fig. 1 as the second service node. For convenience of understanding, in the embodiment of the present application, one node may be selected from the multiple nodes in the core consensus network 100c shown in fig. 1 as a consensus node for performing data separation to the first service node, that is, the consensus node may return separation data corresponding to the data separation request to the first service node, for example, the node 120a shown in fig. 1 may be used as a consensus node for performing data separation to the first service node.
It can be understood that, in the embodiment of the present application, the local cache of the first service node may be referred to as a first node cache, and the local transaction data in the first node cache is referred to as first local transaction data, where the first local transaction data may be understood as transaction data of an uplink to be confirmed, which has been broadcast to the core consensus network by the first service node. Optionally, it may be understood that, in this embodiment of the present application, a local cache does not need to be created in the first service node, so that the first service node may not need to store, in the local cache, the transaction data of the uplink to be confirmed, which is already broadcast to the core consensus network by the first service node.
It is understood that the service scenarios to which the above hierarchical structure is applicable may specifically include: a block synchronization scenario, a transaction query scenario, a cache flush scenario, etc., and specific service scenarios will not be listed here.
For example, in a block synchronization scenario, the first service node may send a data clearing request to the consensus node when block synchronization needs to be performed, and therefore, when receiving the clearing data returned by the consensus node, the first service node may determine the data to be synchronized based on the clearing type of the received clearing data. For example, if the credit type of the credit data includes an exclusive block associated with the first service node, a normal block associated with the first service node, and a normal block not associated with the first service node, the data to be synchronized herein may include a block header of the exclusive block associated with the first service node, a block header of the normal block associated with the first service node, and a block header of the normal block not associated with the first service node; for another example, if the credit type of the credit data includes an exclusive block unrelated to the first service node, the data to be synchronized herein may include a hidden block header corresponding to the exclusive block unrelated to the first service node (the hidden block header herein mainly refers to a block hash and a parent block hash in the exclusive block unrelated to the first service node). At this time, the first service node may synchronize these data to be synchronized in the clearing data to the block header chain of the first service node. Here, the data clearing request may be understood as a block synchronization request. It will be appreciated that the first service node, upon receiving transaction data associated with the first service node in the liquidation data, may confirm that such transaction data has been added to the blockchain.
Alternatively, it should be understood that, when the first service node has the first node cache therein, the first service node may further delete the currently uplink first local transaction data in the first node cache upon determining that the aforementioned transaction data (i.e., the first local transaction data) stored in the first node cache has been added to the blockchain, that is, the first service node may delete the transaction data associated with the first service node in the liquidation data in the first node cache. For example, in a cache clearing scenario, when the cache capacity of the first node cache is insufficient, the first service node may send a data clearing request to the consensus node, so that when receiving the clearing data returned by the consensus node, based on the received clearing data, the transaction data associated with the first service node in the clearing data is deleted in the first node cache.
For another example, in a transaction query scenario, the first service node may send a data clearing request to the consensus node when transaction data needs to be queried. For example, when the police inquires about the specified transaction data from a company, if the company does not have the transaction data that needs to be presented to the police, the company may serve as the first service node to send a data clearing request to the consensus node having the transaction data that needs to be presented, so as to inquire about the transaction data that the company lacks, where the transaction data that the company lacks may belong to the clearing data returned by the consensus node. The data inventory request here can be understood as a data query request.
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. The service node 20a shown in fig. 2 (where the service node 20a may be a first service node) may be any node in the service network 100a in the embodiment corresponding to fig. 1, the proxy node 20b shown in fig. 2 may be the proxy node 100b in the embodiment corresponding to fig. 1, and the consensus node 20c shown in fig. 2 may be any node in the core consensus network 100c in the embodiment corresponding to fig. 1. For convenience of understanding, the embodiment of the present application takes the node 110a shown in fig. 1 as the service node 20a and takes the node 120a shown in fig. 1 as the consensus node 20c as an example, so as to illustrate a specific process of data interaction among the service node 20a, the proxy node 20b, and the consensus node 20c shown in fig. 2.
It should be understood that the service node 20a may execute the transaction service to obtain the transaction data associated with the service node 20a according to the transaction execution result of the transaction service, and further may send the transaction data to the agent node 20b, so that the agent node 20b sends the transaction data to the core consensus network for broadcasting. The transaction service may be an asset transfer service, and the embodiment of the present application does not limit the transaction service. The number of the transaction data may be one or more, and the embodiment of the present application does not limit the number of the transaction data. It is understood that a consensus node (e.g., the consensus node 20 c) in the core consensus network may add transaction data associated with the service node 20a to the local transaction pool when receiving the transaction data associated with the service node 20a, and then perform a packaging process on a part of the transaction data (where the part of the transaction data may include one or more transaction data associated with the service node 20 a) in the local transaction pool in a subsequent step to generate a to-be-verified block, and further may take the to-be-verified block as a target block when the consensus node in the core consensus network agrees with the to-be-verified block, so as to write the target block into a block chain maintained by the consensus node 20 c.
The service node 20a shown in fig. 2, after receiving the uplink notification based on the target zone broadcast by the consensus node 20c in the core consensus network, may send a data clearing request to the consensus node 20c to determine whether the transaction data associated with the service node 20a has been written onto the zone chain maintained by the consensus node 20 c. The block height of the target block on the block chain may be a block height N, and the maximum block height on the block head chain of the service node 20a may be a block height M, where N may be a positive integer greater than M, and where N may be a positive integer. The number of the target blocks may be one or more, that is, the service node 20a may send the data clearing request to the common node 20c after receiving the uplink notification based on one target block, and may also send the data clearing request to the common node 20c after receiving the uplink notification based on a plurality of target blocks, which is not limited in this application. Further, the service node 20a may generate a data clearing request based on the determined block height M and the block height N, and may further send the data clearing request to the proxy node 20b, so that the proxy node 20b forwards the data clearing request to the consensus node 20c in the core consensus network.
As shown in fig. 2, the consensus node 20c may determine (N-M) blocks on the locally maintained block chain 200a based on the block height N and the block height M carried in the data inventory request. Here, the number of tiles in the tile chain 200a is N, where the N tiles may include tile 1, tile 2, …, tile M, tile (M +1), …, and tile N; here, the (N-M) blocks may include block (M +1), block (M +2), …, block (N-1), and block N. Further, the consensus node 20c may obtain the to-be-processed block (e.g., to-be-processed block 200 b) from the (N-M) blocks, where the to-be-processed block 200b may be block N, and thus, after performing the block identification on the block N, the consensus node 20c may obtain, upon determining that the block N is the first type of exclusive block (i.e., the exclusive block associated with the service node 20a, where the transaction data in the exclusive block associated with the service node 20a is the transaction data associated with the service node 20 a), the block anchor information in the block N, through which the to-be-processed block is located to the anchor location block (e.g., anchor location block 200 c) associated with the first type of exclusive block, where the anchor location block 200c may be block (M +2), based on the block type of the anchor location block 200c, the score data corresponding to anchor positioning block 200c is determined, for example, the score data of anchor positioning block 200c may be the first score data.
As shown in fig. 2, when determining the first clearing data corresponding to the anchor positioning block 200c, the consensus node 20c may return the first clearing data to the proxy node 20b, so that the proxy node 20b forwards the first clearing data to the service node 20 a. Optionally, it may be understood that, based on the block type of the to-be-processed block 200b (i.e., the block type of the first exclusive block), the consensus node 20c may also determine the credit data (e.g., fifth credit data) corresponding to the to-be-processed block 200b, so as to forward the credit data corresponding to the to-be-processed block 200b to the service node 20a through the proxy node 20 b. Optionally, it may be understood that the consensus node 20c may also determine the respective liquidation data (e.g., sixth liquidation data) of the blocks (N-M) except the anchor positioning block 200c and the to-be-processed block 200b based on the block types of the blocks (i.e., block (M +1), block (M +3) (not shown in the figure), …, and block (N-1)) to forward the liquidation data to the service node 20a through the proxy node 20 b.
It should be understood that, in a hierarchical block chain structure of "service network-core consensus network", the service node 20a in the service network may send a data clearing request to the consensus node 20c in the core consensus network through the proxy node 20b when requesting data clearing. In this way, the consensus node 20c may determine (N-M) blocks to be subjected to data separation in the block chain, perform block identification on the (N-M) blocks to obtain block types of the (N-M) blocks, determine separation data for returning to the service node 20a based on the block types of the (N-M) blocks, and further return the separation data to the service node 20a through the proxy node 20 b. It can be understood that, the (N-M) blocks herein include a first type exclusive block (e.g., block N), and the block anchor information in the first type exclusive block can be used to quickly locate the anchor positioning block (e.g., block (M + 2)) associated with the first type exclusive block, so as to quickly obtain the first clearing data corresponding to the anchor positioning block, and therefore, the search duration from the consensus node to the transaction data associated with the first service node (i.e., service node 20 a) can be effectively reduced through the block anchor information, thereby improving the efficiency of data clearing. Furthermore, by skipping blocks between the first exclusive block type and the anchor positioning block (e.g., block (N-1)), the transaction data within block (N-1) may not need to be returned to the first service node, and thus privacy isolation of the transaction data within block (N-1) may be achieved. Similarly, for transaction data associated with the first service node in the first exclusive block, the transaction data will not be returned as liquidation data to service nodes (e.g., second service nodes) other than the first service node in the service network, and thus privacy isolation of the transaction data in the first exclusive block can be achieved.
For a specific implementation manner of data interaction among the service node 20a, the agent node 20b, and the consensus node 20c, reference may be made to the following description of data interaction among the first service node, the agent node, and the consensus node in the embodiments corresponding to fig. 3 to fig. 10.
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 consensus node in a core consensus network, where the consensus 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 consensus node is not limited herein. The consensus node may be any one of the nodes in the core consensus network 100c shown in fig. 1, described above, such as node 120 a. The transaction data processing method at least comprises the following steps S101-S104:
step S101, receiving a data clearing request forwarded by a first service node in a service network through a proxy node;
the proxy node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request may carry a block height M and a block height N, where the block height M is a maximum block height on a block head chain stored by the first service node, and the block height N is a maximum block height on a block chain maintained by the common node. Where N may be a positive integer, and where M may be a positive integer less than N.
For ease of understanding, please refer to fig. 4, and fig. 4 is a schematic view of a scenario for sending a data liquidation request according to an embodiment of the present application. The service node 40a shown in fig. 4 may be a first service node that sends a data accounting request, and the service node 40a may be any one of the nodes in the service network 100a shown in fig. 1, for example, the node 110 a; the consensus node 40c shown in fig. 4 may be a consensus node that receives a data credit request, and the consensus node 40c may be any one of the nodes in the core consensus network 100c shown in fig. 1, for example, the node 120 a; the proxy node 40b shown in fig. 4 may be used for network isolation between the service network and the core consensus network, and the proxy node 40b may be the proxy node 100b shown in fig. 1.
As shown in fig. 4, the service node 40a may be a lightweight node, and the service node 40a may store a block header chain 4a, where the block header chain 4a specifically includes: block header 1, block header 2, …, block header M, which may be a positive integer. As shown in fig. 4, the common node 40c may be a full node, the common node 40c may store a block chain 4b, and the block chain 4b may specifically include: tile 1, tile 2, …, tile M, tile (M +1), …, tile N, where N may be a positive integer greater than M. Wherein each tile may include a tile head and a tile body, e.g., tile 1 may include tile head 1 and tile bodies 1, …, tile M may include tile head M and tile bodies M, …, tile N may include tile head N and tile body N.
It is understood that, when performing data cleaning, the service node 40a may obtain, from the locally stored block header chain 4a, a block height corresponding to the block header with the largest block height (i.e., the block height corresponding to the block header with the largest block generation timestamp), that is, a block height corresponding to the block header M, for example, the block height M. Further, the service node 40a may obtain a block height corresponding to a block with the largest block height (i.e., a block height corresponding to a block with the largest block generation timestamp) on the blockchain 4b maintained by the common node (e.g., the common node 40 c) in the blockchain system, i.e., a block height corresponding to the block N, e.g., the block height N. Further, the service node 40a may generate a data sorting request based on the obtained block height M and the obtained block height N, and further send the data sorting request to the proxy node 40b, so that the proxy node 40b forwards the data sorting request to the consensus node 40 c.
It is understood that, upon receiving the data liquidation request forwarded by the proxy node 40b, the consensus node 40c may obtain the block height M and the block height N from the data liquidation request, and then perform the following step S102 based on the block height M and the block height N to determine (N-M) blocks from the block height M to the block height N on the block chain 4b, where the (N-M) blocks may be the blocks (M +1), …, and the block N shown in fig. 4.
Optionally, the service node 40a may further generate a data score clearing request based on the obtained block height M, and further send the data score clearing request containing the block height M to the proxy node 40 b. In this way, when receiving the data sorting request forwarded by the proxy node 40b, the consensus node 40c may obtain the block height N corresponding to the block N on the block chain 4b stored in the consensus node 40c, and further determine (N-M) blocks from the block height M to the block height N on the block chain 4b based on the block height N and the block height M obtained in the data sorting request.
Step S102, determining (N-M) blocks from a block height M to a block height N on a block chain based on a data sorting request, acquiring a block to be processed in a block height decreasing direction of the (N-M) blocks, and performing block identification on the block to be processed to obtain a block identification result;
specifically, the consensus node may determine (N-M) blocks from a block height M to a block height N on the block chain based on the data clearing request, and mark the block identification status of the determined (N-M) blocks as the to-be-identified status. Further, the consensus node may identify, among the (N-M) blocks, a block having the maximum block height and identifying the state to be identified as the block to be processed, the block identification information in the block to be processed. Further, when the common identification node identifies that the block identification information is the first type of block identification information, the block type of the block to be processed is used as the first block type, the block identification state of the block to be processed with the first block type is marked as the identified state by the state to be identified, the block to be processed with the first block type and marked with the identified state is used as the exclusive block to be classified, and the node identification information in the exclusive block to be classified is acquired. Further, if the obtained node identification information is a first class node identification associated with the first service node, the consensus node may determine the exclusive block to be classified as a first class exclusive block associated with the first service node, take the first class exclusive block as a first exclusive identification result, and add the first exclusive identification result to the block identification result corresponding to the block to be processed. The first exclusive identification result is used for executing the step of acquiring the block anchoring information in the first type of exclusive block when the block to be processed is the first type of exclusive block.
It is understood that the (N-M) blocks from block height M to block height N may be blocks having block height (M +1), block height (M +2), …, and block height N. For example, when M is equal to 5 and N is equal to 10, 5 blocks from block height 5 to block height 10 may be blocks having block height 6, block height 7, block height 8, block height 9, and block height 10.
It is understood that the first to-be-processed block acquired by the common node in the (N-M) blocks may be a block with a block height N (e.g., block N), and after block identification is performed on the block N, the block identification status of the block N may be updated to the identified status. Further, the common node may acquire a second to-be-processed block among the (N-M) blocks, the acquired second to-be-processed block may be a block having a block height (N-1) (e.g., block (N-1)), and after performing block identification on the block (N-1), the block identification status of the block (N-1) may be updated to the identified status. And so on, until the consensus node acquires the last block to be processed among the (N-M) blocks, the acquired last block to be processed may be a block having a block height (M +1) (e.g., block (M + 1)) or a block having a block height smaller than the block height (M-1).
It should be understood that the block identification information may be stored in a block header of the block to be processed, and may also be stored in a block body of the block to be processed, and the storage location of the block identification information in the block to be processed is not limited in the embodiments of the present application. Similarly, it should be understood that the node identification information may be stored in a block header of the exclusive block to be classified, and may also be stored in a block body of the exclusive block to be classified.
Optionally, the block identifier information and the node identifier information may be the same identifier information, and the consensus node may divide the to-be-processed block based on the block identifier information. For example, when the block identifier information is an identifier G1 (for example, the identifier G1 may be used to identify an identity of the first service node), the consensus node may determine that the identifier G1 is the first type identifier information, and further determine that the identifier G1 is the first type node identifier associated with the first service node, that is, the consensus node may determine that the identifier G1 is the first type identifier information, or may determine that the identifier G1 is the first type node identifier.
It should be understood that the service network includes a second service node. The second service node may be any service node except the first service node in the service network. Optionally, it may be understood that, if the obtained node identification information is a second class node identification associated with a second service node, the consensus node may determine the exclusive block to be classified as a second class exclusive block unrelated to the first service node, take the second class exclusive block as a second exclusive recognition result, and add the second exclusive recognition result to the block recognition result corresponding to the block to be processed.
It is to be understood that the exclusive blocks to be categorized may include a first type of exclusive blocks and a second type of exclusive blocks, the first type of exclusive blocks and the second type of exclusive blocks may be collectively referred to as exclusive blocks, the block type of the exclusive blocks may be a first block type, the first block type may include a first exclusive type and a second exclusive type, the block type of the first type of exclusive blocks may be a first exclusive type, and the block type of the second type of exclusive blocks may be a second exclusive type.
Wherein a first type of exclusive block associated with a first service node (i.e., an exclusive block associated with the first service node) may include transaction data associated with the first service node, which may include an exclusive transaction associated with the first service node and a normal transaction associated with the first service node. Wherein the second type of exclusive block unrelated to the first service node (i.e., the exclusive block unrelated to the first service node) may include transaction data associated with the second service node, and the transaction data associated with the second service node may include an exclusive transaction associated with the second service node and a normal transaction associated with the second service node.
It should be understood that, when the block identification result corresponding to the block to be processed is the first exclusive identification result, the common node may perform the following steps S203 to S204. It is understood that, when the block identification result corresponding to the block to be processed is the second exclusive identification result, the consensus node may perform the following steps: if the block identification result includes the second exclusive identification result, the common identification node may hide the data of the second type of exclusive block based on the second type of exclusive block indicated by the second exclusive identification result, so as to obtain a block hash of the second type of exclusive block and a parent block hash of the second type of exclusive block. Further, the consensus node may use the block hash of the second exclusive block and the parent block hash of the second exclusive block as second credit data of the first service node, and return the second credit data to the first service node through the proxy node. The block hash of the second exclusive block and the parent block hash of the second exclusive block may be collectively referred to as a hidden block header corresponding to the second exclusive block.
Alternatively, it may be understood that, when recognizing that the block identification information is the second type of block identification information, the common node may regard the block type of the to-be-processed block as the second block type, mark the block identification state of the to-be-processed block having the second block type as the identified state from the to-be-identified state, regard the to-be-processed block having the second block type and identified with the identified state as the non-exclusive block to be classified, and filter the transaction data associated with the first service node in the non-exclusive block to be classified. Further, if transaction data associated with the first service node is screened from the non-exclusive blocks to be classified, the consensus node may determine the non-exclusive blocks to be classified as first non-exclusive blocks of a first type associated with the first service node, take the first non-exclusive blocks of the first type as first non-exclusive identification results, and add the first non-exclusive identification results to block identification results corresponding to the blocks to be processed.
It is understood that, when the block identification result corresponding to the block to be processed is the first non-exclusive identification result, the consensus node may perform the following steps: if the block identification result includes the first non-exclusive identification result, the common identification node may use transaction data associated with the first service node in the first non-exclusive block as the first transaction data based on the first non-exclusive block indicated by the first non-exclusive identification result. Further, the consensus node may obtain a block header of the first non-exclusive block and first merkel certification information corresponding to the first transaction data, use the first transaction data, the first merkel certification information, and the block header of the first non-exclusive block as third clearing data of the first service node, and return the third clearing data to the first service node through the proxy node.
Alternatively, it can be understood that, if the transaction data associated with the first service node is not screened from the non-exclusive blocks to be classified, the consensus node may determine the non-exclusive blocks to be classified as a second type of non-exclusive blocks unrelated to the first service node, take the second type of non-exclusive blocks as a second non-exclusive recognition result, and add the second non-exclusive recognition result to the block recognition result corresponding to the block to be processed.
It is to be understood that the non-exclusive blocks to be categorized may include a first type of non-exclusive blocks and a second type of non-exclusive blocks, the first type of non-exclusive blocks and the second type of non-exclusive blocks may be collectively referred to as normal blocks (i.e., non-exclusive blocks), the block type of the normal blocks may be a second block type, the second block type may include a first non-exclusive type and a second non-exclusive type, the block type of the first type of non-exclusive blocks may be a first non-exclusive type, and the block type of the second type of non-exclusive blocks may be a second non-exclusive type.
Wherein a first type of non-exclusive tile associated with a first service node (i.e., a common tile associated with the first service node) may comprise transaction data associated with the first service node, which may comprise a common transaction associated with the first service node. Wherein the second type of non-exclusive block not associated with the first service node (i.e., the normal block not associated with the first service node) may include transaction data associated with the second service node, which may include normal transactions associated with the second service node.
Optionally, the first type of non-exclusive sector block associated with the first service node may further comprise transaction data associated with the second service node, which may comprise a common transaction associated with the second service node.
It should be understood that, in the embodiments of the present application, the number of service nodes to which transaction data in the first type of non-exclusive block and the second type of non-exclusive block belong is not limited, that is, the first type of non-exclusive block and the second type of non-exclusive block may include transaction data associated with one or more service nodes, and the embodiments of the present application do not limit the number of one or more service nodes herein.
It can be understood that, when the block identification result corresponding to the block to be processed is the second type non-exclusive identification result, the common node may perform the following steps: if the block identification result includes the second non-exclusive identification result, the common identification node may use a block header of the second non-exclusive block as fourth clearing data of the first service node based on the second non-exclusive block indicated by the second non-exclusive identification result, and return the fourth clearing data to the first service node through the proxy node.
It is to be appreciated that the exclusive tiles associated with the first service node and the ordinary tiles associated with the first service node can be collectively referred to as the tiles associated with the first service node, and the exclusive tiles not associated with the first service node and the ordinary tiles not associated with the first service node can be collectively referred to as the tiles not associated with the first service node.
Step S103, if the block identification result indicates that the block to be processed is a first exclusive block associated with the first service node, acquiring block anchoring information in the first exclusive block, positioning the block associated with the first service node in the (N-M) blocks through the block anchoring information, and determining the positioned block as an anchoring positioning block;
the block height of the anchor positioning block is smaller than that of the block to be processed, and the block between the anchor positioning block and the block to be processed is a block which is skipped based on the block anchor information and is irrelevant to the first service node.
It should be understood that the block anchor information may be stored in a block header of the first type exclusive block, and may also be stored in a block body of the first type exclusive block, and the storage location of the block anchor information in the first type exclusive block is not limited in this embodiment of the application.
It should be understood that the packing node (i.e., the consensus node that packs the transaction data) may generate the block anchor information of the first type of exclusive block when the first type of exclusive block is obtained by packing. It is to be understood that the consensus node may determine the anchor associated block having the largest block generation timestamp (i.e., having the largest block height) and associated with the first service node on the block chain, and obtain the block anchor identity of the anchor associated block. The block type of the anchor associated block is the same as the block type of the first exclusive block or the block type of the first non-exclusive block. Further, when the first-class exclusive blocks to be broadcasted to the core consensus network are obtained by packaging, the consensus node may use the block anchor identifier of the anchor associated block as the block anchor information of the first-class exclusive blocks, store the block anchor information into the first-class exclusive blocks, and further broadcast the first-class exclusive blocks carrying the block anchor information obtained by packaging to the core consensus network. At this time, the anchor associated block is the anchor located block associated with the first exclusive block.
It is to be understood that the block anchor id herein can be used to uniquely identify the anchor associated block. The block anchor id of the anchor associated block may be the block height of the anchor associated block or may be the block hash of the anchor associated block. It should be understood that the embodiments of the present application do not limit the specific value of the block anchor identifier for anchoring the associated block.
Alternatively, it should be understood that the common node may generate the block anchor information of the first type of exclusive block when uplink is performed on the first type of exclusive block (i.e., the first type of exclusive block is added to the block chain maintained by the common node). It is to be understood that the consensus node may determine the anchor associated block having the largest block generation timestamp (i.e., having the largest block height) and associated with the first service node on the block chain, and obtain the first anchor identity of the anchor associated block. The block type of the anchor associated block is the same as the block type of the first exclusive block or the block type of the first non-exclusive block. Further, the consensus node may perform uplink on the first type of exclusive block when the consensus result indicating that the consensus is passed when the core consensus network performs the consensus on the first type of exclusive block indicates that the consensus passes, and at this time, the consensus node may obtain a second anchor identifier of the first type of exclusive block, and store the first anchor identifier and the second anchor identifier in an anchor information list of the consensus node. Further, the consensus node may determine a data relationship between the first anchor identifier and the second anchor identifier as the block anchor information of the first type of exclusive block, and store the block anchor information into the first type of exclusive block.
It should be understood that specific values of the first anchor identifier of the anchor associated block and the second anchor identifier of the first exclusive block may refer to the above description of the block anchor identifier of the anchor associated block, which will not be described herein again.
Here, it is understood that the block anchor information herein may represent a pointer for pointing to a data relationship of the first anchor identifier and the second anchor identifier in the anchor information list. The consensus node may obtain, according to a position pointed by the block anchor information in the anchor information list, a data relationship between the first anchor identifier and the second anchor identifier in the anchor information list, determine that the anchor identifier corresponding to the first type of exclusive block is the second anchor identifier, and the anchor identifier corresponding to the second anchor identifier is the first anchor identifier, and further use the block corresponding to the first anchor identifier as the located anchor location block associated with the first type of exclusive block.
Optionally, it may be understood that the consensus node may also directly search the anchor identifier of the first exclusive block in the anchor information list without storing the block anchor information into the first exclusive block, and further search the second anchor identifier in the anchor information list, determine, based on a data relationship between the first anchor identifier and the second anchor identifier in the anchor information list, that the anchor identifier corresponding to the second anchor identifier is the first anchor identifier, and further use the block corresponding to the first anchor identifier as the located anchor positioning block associated with the first exclusive block.
Step S104, based on the block type of the anchoring positioning block, determining first clearing data for returning to the first service node, and returning the first clearing data to the first service node through the proxy node.
Specifically, if the block type of the anchor positioning block is the same as the block type of the first exclusive block, the consensus node may use the anchor positioning block as the first sub-credit data of the first service node. Further, if the block type of the anchor positioning block is different from the block type of the first exclusive block, the consensus node may obtain key service data information associated with the first service node in the anchor positioning block, and use the obtained key service data information as second sub-credit data of the first service node. Further, the consensus node may use the first sub-score clearing data or the second sub-score clearing data as the first score clearing data of the first service node, and return the first score clearing data to the first service node through the proxy node.
It is to be understood that the block type of the anchor located block may be a first exclusive type of the first block type or a first non-exclusive type of the second block type, and the block type of the first exclusive block is a first exclusive type of the first block type. If the block type of the anchor positioning block is the same as that of the first exclusive block, the block type of the anchor positioning block is the first exclusive type, and at the moment, the anchor positioning block is the first exclusive block; if the block type of the anchor positioning block is different from the block type of the first exclusive block, the block type of the anchor positioning block is a first non-exclusive type, and at this time, the anchor positioning block is a first non-exclusive block.
It can be understood that the specific process of the consensus node for acquiring the key service data information associated with the first service node in the anchor positioning block can be described as follows: the consensus node may use the transaction data associated with the first service node in the anchor positioning block as the second transaction data. Further, the consensus node may obtain a block header of the anchor positioning block and second mercker certification information corresponding to the second transaction data, and use the second transaction data, the second mercker certification information, and the block header of the anchor positioning block as key service data information associated with the first service node.
It should be appreciated that the consensus node may use the first type of exclusive block as the fifth credit data of the first service node. Further, the consensus node may determine, among the (N-M) tiles, a tile between the anchor positioning tile and the first type of exclusive tile as a traffic filter tile unrelated to the first traffic node, based on a tile type of the traffic filter tile, sixth clearing data for return to the first traffic node. Further, the consensus node may return the fifth clearing data and the sixth clearing data to the first service node through the proxy node.
The transaction data associated with the first service node can be processed in a batch and centralized manner based on the mode of the first exclusive block, so that privacy isolation of the transaction data is realized, and the first exclusive block can be flexibly and efficiently returned to the first service node directly when the data is cleared.
It is to be understood that the block type of the traffic filter block may be a second exclusive type in the first block type or a second non-exclusive type in the second block type. If the block type of the service filtering block is the second exclusive type (that is, the block type of the service filtering block is the same as the block type of the second exclusive block), the common node may obtain third sub-credit data associated with the first service node in the service filtering block; if the block type of the service filtering block is the second non-exclusive type (i.e. the block type of the service filtering block is the same as the block type of the second non-exclusive type), the common node may obtain the fourth sub-credit data associated with the first service node in the service filtering block.
It should be understood that, for a specific process of the consensus node acquiring the third sub-score data associated with the first service node in the service filtering block, reference may be made to the above description of determining the second score data associated with the first service node, and details will not be described here. It should be understood that, for a specific process of the consensus node acquiring the fourth sub-score data associated with the first service node in the service filtering block, reference may be made to the above description of determining the fourth score data associated with the first service node, and details will not be described here.
One or more service filtering blocks may be located between the anchor positioning block and the first type exclusive block, and the consensus node may determine, as sixth clearing data associated with the first service node, third sub-clearing data or fourth sub-clearing data corresponding to each of the one or more service filtering blocks. For example, when the number of the traffic filtering blocks is two, the two traffic filtering blocks may be a block Q1 and a block Q2, if the block type of the block Q1 is the second exclusive type, and if the block type of the block Q2 is the second non-exclusive type, the common node may determine the third sub-liquidation data corresponding to the block Q1 and the fourth sub-liquidation data corresponding to the block Q2 as the sixth liquidation data associated with the first traffic node. It should be understood that the number of the traffic filter blocks is not limited in the embodiments of the present application.
Optionally, the block located by the common node through the block anchor information in the first exclusive block may not belong to the (N-M) blocks, where the block outside the (N-M) blocks located by the common node through the block anchor information may be determined as the auxiliary locating block. Further, the consensus node may use the block between the first type exclusive block and the auxiliary positioning block as an auxiliary filtering block independent of the first service node. Further, the consensus node may determine a block belonging to (N-M) blocks of the auxiliary filter blocks as a first filter block, determine a block not belonging to (N-M) blocks of the auxiliary filter blocks as a second filter block, and determine seventh clearing data for returning to the first service node based on a block type of the first filter block. Further, the consensus node may return the seventh clearing data to the first service node through the proxy node.
Here, it is to be understood that the block type of the first filtering block may be a second exclusive type in the first block type or a second non-exclusive type in the second block type. It should be understood that, for a specific process of the consensus node determining the seventh score data associated with the first service node, reference may be made to the above description of determining the sixth score data associated with the first service node, and details will not be described here.
It can be understood that the consensus node may use the first clearing data, the second clearing data, the third clearing data, the fourth clearing data, the fifth clearing data, and the sixth clearing data as all clearing data, and then return all clearing data to the first service node through the proxy node. For a block to be processed, all the score clearing data includes a score clearing data associated with the block to be processed, and all the score clearing data does not include multiple score clearing data corresponding to the same block to be processed. Optionally, it may be understood that, when the consensus node respectively acquires the first clearing data, the second clearing data, the third clearing data, the fourth clearing data, the fifth clearing data, and the sixth clearing data, the clearing data may be respectively returned to the first service node through the proxy node.
For example, when the block Q1 is an exclusive block of the first type, the block located by the block anchor information in the block Q1 is the block Q2, the consensus node may determine the first credit data for returning to the first service node based on the block type of the block Q2, and when the block Q2 is a new block to be processed, if the block Q2 is an exclusive block of the first type, the consensus node may return the fifth credit data based on the block Q2, where the fifth credit data and the first credit data are credit data corresponding to the block Q2. Wherein, the consensus node can add the fifth liquidation data or the first liquidation data to the total liquidation data.
For ease of understanding, please refer to fig. 5, and fig. 5 is a schematic flow chart illustrating a process of determining score data according to an embodiment of the present application. A flow chart of determining the liquidation data for the consensus node for returning to the first service node is shown in steps S501-S514 of fig. 5. The consensus node may perform step S501 to receive a data separation request forwarded by a first service node in the service network through the proxy node, and further perform step S502, determine (N-M) blocks from the block height M to the block height N on the block chain based on the data separation request, obtain a block to be processed in a direction in which the block heights of the (N-M) blocks decrease, perform block identification on the block to be processed, and obtain a block identification result.
Further, the common node may perform step S503 to determine whether the block identification information of the block to be processed is the first type block identification information, and perform step S504 if the block identification information of the block to be processed is the first type block identification information. Optionally, if the block identifier information of the to-be-processed block is not the first type block identifier information (i.e. the second type block identifier information), step S511 is executed.
As shown in fig. 5, the consensus node may determine whether the node identification information of the to-be-processed block is the first type node identification or not when performing step S504, and perform step S505 if the node identification information of the to-be-processed block is the first type node identification (i.e., it is determined that the to-be-processed block is the first type exclusive block associated with the first service node). Optionally, if the node identifier information of the block to be processed is not the first type of node identifier (i.e. the second type of node identifier, and it is determined that the block to be processed is the second type of exclusive block unrelated to the first service node), step S509 is executed.
When the common node performs step S505, it may obtain the block anchor information in the first type exclusive block, locate a block associated with the first service node among the (N-M) blocks through the block anchor information, determine the located block as an anchor location block, and then perform step S506, and determine first score data for returning to the first service node based on the block type of the anchor location block. Further, the consensus node may perform steps S507 and S508, taking the first type exclusive block as fifth clearing data of the first service node, and among the (N-M) blocks, taking a block between the anchor positioning block and the first type exclusive block as a service filtering block unrelated to the first service node, and determining sixth clearing data for returning to the first service node based on a block type of the service filtering block.
Optionally, when the common node performs step S509, the common node may hide the data of the second type of exclusive block to obtain a block hash of the second type of exclusive block and a parent block hash of the second type of exclusive block, and then perform step S510 to use the block hash of the second type of exclusive block and the parent block hash of the second type of exclusive block as the second clearing data of the first service node. It is understood that, after obtaining the second liquidation data, the consensus node may obtain a previous block with a block height smaller than the second exclusive block, and take the previous block as a new block to be processed.
As shown in fig. 5, the consensus node may determine whether the to-be-processed block includes transaction data associated with the first service node when performing step S511, and perform step S512 if the to-be-processed block includes transaction data associated with the first service node (i.e., it is determined that the to-be-processed block is a first non-exclusive block of a first type associated with the first service node). Alternatively, if the pending block does not contain transaction data associated with the first service node (i.e. it is determined that the pending block is a non-exclusive block of the second type independent of the first service node), step S514 is performed.
When the consensus node performs step S512, the transaction data associated with the first service node in the first non-exclusive block may be used as the first transaction data, and then step S512 is performed to obtain a block header of the first non-exclusive block and first tacher certification information corresponding to the first transaction data, and use the first transaction data, the first tacher certification information, and the block header of the first non-exclusive block as the third clearing data of the first service node. It is understood that, after obtaining the third sorting data, the consensus node may obtain a previous block with a block height smaller than the first non-exclusive block, and take the previous block as a new block to be processed.
Optionally, when the common node performs step S514, the block header of the second type of non-exclusive block may be used as the fourth clearing data of the first service node. It is understood that, after obtaining the fourth sorting data, the consensus node may obtain a previous block with a block height smaller than the second non-exclusive block, and take the previous block as a new block to be processed.
For easy understanding, please refer to fig. 6, and fig. 6 is a schematic view of a scene for data hiding according to an embodiment of the present application. The consensus node 60a shown in fig. 6 may be a consensus node that receives a data credit request, and the consensus node 60a may be any one of the nodes in the core consensus network 100c shown in fig. 1, for example, the node 120 a. As shown in fig. 6, the blockchain 6a may include a block 1, …, and a block N, where the block 1, …, and the block N may be the block 1, …, and the block N in the embodiment corresponding to fig. 4, and the common node 60a may obtain (N-M) blocks from the block height M to the block height N, that is, obtain the blocks (M +1), …, and the block N.
As shown in fig. 6, the common node 60a may determine the to-be-processed block in the blockchain 6a, for example, the common node 60a may determine the block N as the to-be-processed block 6b in the blockchain 6a, and the block information of the to-be-processed block 6b may include a block header (i.e., block header information) and a block body (i.e., block body information). The block header may include information such as a parent block hash value of the block to be processed 6b (i.e., a block hash value and a parent block hash value of a block (N-1) (not shown), a block height, a version number, a timestamp, a difficulty value, a random number, and a mercker tree root (i.e., a block hash and a block hash value), and the block body may include transaction data packed into the block to be processed 6b and a mercker path formed by the transaction hash values of the transaction data.
For convenience of understanding, the number of the transaction data packed into the to-be-processed block 6b is taken as 4 as an example for description, and the 4 transaction data may be the transaction data 51, the transaction data 52, the transaction data 53 and the transaction data 54 shown in fig. 6. For example, the transaction Hash value of the transaction data 51 may be a transaction Hash value 1 (e.g., Hash 1), the transaction Hash value of the transaction data 52 may be a transaction Hash value 2 (e.g., Hash 2), the transaction Hash value of the transaction data 53 may be a transaction Hash value 3 (e.g., Hash 3), and the transaction Hash value of the transaction data 54 may be a transaction Hash value 4 (e.g., Hash 4).
As shown in fig. 6, it can be understood that, when the to-be-processed block 6b is an exclusive block of the second type, the common node 60a may perform data hiding on the to-be-processed block 6b to obtain a block hash and a parent block hash of the to-be-processed block 6b, that is, the common node 60a may perform data hiding on the to-be-processed block 6b to obtain a hidden block header 60b corresponding to the to-be-processed block 6b, and the hidden block header 60b may include the block hash and the parent block hash. Further, the consensus node may use the hidden block header 60b as the credit data (i.e., the second credit data) returned to the first service node.
Optionally, it may be understood that, when the to-be-processed block 6b is the first-type exclusive block, the consensus node 60a may directly use the to-be-processed block 6b as the credit data (i.e., the fifth credit data) returned to the first service node, where the credit data may include the block header and the block body of the to-be-processed block 6 b.
Alternatively, it may be understood that, when the to-be-processed tile 6b is a first type non-exclusive tile, the consensus node 60a may use the transaction data associated with the first service node in the to-be-processed tile 6b as the first transaction data, for example, the transaction data associated with the first service node in the to-be-processed tile 6b may be the transaction data 53 and the transaction data 54, and thus, the consensus node 60a may use the transaction data 53 and the transaction data 54 as the first transaction data. Further, the consensus node 60a may obtain first merkel proof information corresponding to the first transaction data, where the first merkel proof information may be formed by a transaction Hash value in a merkel path, for example, where Hash12 and Hash1234 may be used as a path Hash value to form the first merkel proof information according to the path Hash value. Further, the consensus node 60a may use the first transaction data, the first merkel proof information, and the block header of the pending block 6b as the score clearing data (i.e., the third score data) returned to the first service node.
Alternatively, it can be understood that, when the to-be-processed block 6b is a non-exclusive block of the second type, the common node 60a may use the block header of the to-be-processed block 6b as the clearing data (i.e., the fourth clearing data) returned to the first service node.
Therefore, the embodiment of the application can realize the function of the network node in the hierarchical block chain structure of the service network-core consensus network, performing block identification on the to-be-processed blocks sequentially acquired from the (N-M) blocks, so as to anchor information by the blocks in the first type exclusive blocks when the acquired to-be-processed blocks are determined to be the first type exclusive blocks, based on the fast positioning of the anchor positioning block associated with the first exclusive block in the (N-M) blocks, when the liquidation data (e.g., the first liquidation data) corresponding to the data liquidation request is returned for the first service node, the embodiments of the present application may fast skip the blocks unrelated to the first service node by the block anchor information, and meanwhile, the data is cleared to the anchoring positioning block associated with the first service node, so that the data clearing efficiency can be improved. Furthermore, for those skipped traffic filtering blocks that are not associated with the first service node, the transaction data within those traffic filtering blocks will not be returned as credit data to the first service node in the traffic network, thus enabling privacy isolation of the transaction data within those traffic filtering blocks.
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 first service node in the service network, a proxy node, and a consensus node in the core consensus network. The first service node may be any one of the nodes in the service network 100a shown in fig. 1, for example, the node 110 a; the proxy node may be proxy node 100b shown in FIG. 1 above; the consensus node may be any one of the nodes in the core consensus network 100c shown in fig. 1, described above, such as node 120 a. The transaction data processing method can comprise the following steps:
step S201, a first service node acquires a block height M and a block height N, and generates a data clearing request based on the block height M and the block height N;
wherein, the block height M is a maximum block height on a block head chain stored by the first service node, and the block height N is a maximum block height on a block chain maintained by a consensus node in the core consensus network. Where N may be a positive integer, and where M may be a positive integer less than N.
Optionally, the first service node may also request data liquidation of the transaction data in the blocks within the specified time interval, for example, the start time of the time interval may be time T1, and the end time of the time interval may be the next time (for example, time T2) of time T1. Therefore, the first service node may generate the data clearing request based on time T1 and time T2, so that the consensus node acquires K blocks on the block chain whose block generation timestamps belong to time T1 to time T2, and acquires the blocks to be processed in the descending direction of the block heights of the K blocks to perform the subsequent steps. Wherein K may be a positive integer.
Optionally, the first service node may also directly generate a data score clearing request without determining the block height M and the block height N, and further send the data score clearing request to the consensus node in step S202, so that the consensus node returns score clearing data.
Step S202, a first service node sends a data clearing request to a consensus node through a proxy node;
the proxy node is used for carrying out network isolation on the core consensus network and the service network.
For a specific process of the first service node sending the data clearing request to the consensus node, reference may be made to the description in the embodiment corresponding to fig. 4, which will not be described herein again.
Step S203, the consensus node receives a data clearing request forwarded by a first service node in the service network through the proxy node;
the data sorting request carries a block height M and a block height N.
It should be understood that, since the core consensus network is in a relatively secure private cloud, the mutual access of the core consensus network is guaranteed by the consensus mechanism, and no additional identity management and network control need to be added, while the service network is in a public network and can be accessed by other uncertain network terminals. Therefore, the behavior of the service node and possibly other nodes in accessing the consensus network needs to be tightly controlled. Thus, the agent node and the consensus node need to authenticate the first service node sending the data clearing request.
It is understood that, when receiving the data liquidation request sent by the first service node, the proxy node may perform permission verification on the first service node to obtain a permission verification result, where the permission verification may include verifying whether a node identifier (e.g., a first node identifier) of the first service node belongs to node identifiers in an illegal node list. The illegal node list may be a blacklist stored in the proxy node, and the illegal node corresponding to the illegal node identifier in the illegal node list may be a detected malicious node, a node reported by others, a node with an abnormal transaction frequency sent at a certain time period, and the like.
It can be understood that the proxy node may search the illegal node identifier that is the same as the first node identifier of the first service node in the illegal node list to obtain the authority verification result. If the authority verification result indicates that the illegal node identifier which is the same as the first node identifier is found in the illegal node list, the proxy node can determine that the authority verification result belongs to the illegal verification result, and at the moment, the proxy node can determine that the first service node is the illegal node, so that the data sorting request does not need to be forwarded to the common node in the core common node network. Optionally, if the permission verification result indicates that an illegal node identifier identical to the first node identifier is not found in the illegal node list, the proxy node may determine that the permission verification result belongs to a legal verification result, and at this time, the proxy node may determine that the first service node is a legal node, and may further forward the data clearing request to the common node in the core common node network.
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. The node identification list may store node identifications and node names of nodes visible to certain transaction data. The node identifier may be an IP (Internet Protocol) address and any other information that can be used to identify the node, and table 1 only illustrates the IP address as an example. As shown in table 1:
TABLE 1
Figure 252163DEST_PATH_IMAGE001
It is understood that the consensus node may obtain the first encrypted data information sent by the proxy node. The first encrypted data information may be obtained by the proxy node encrypting the data clearing request and the first signature information through a system public key of the consensus network, and the first signature information may be obtained by the first service node in the service network signing the data clearing request through a node private key of the first service node. Further, the consensus node may obtain a system private key of the consensus network (i.e., a system private key corresponding to the system public key of the consensus network), and decrypt the first encrypted data information through the system private key of the consensus network to obtain the data clearing request and the first signature information. Further, the consensus node may obtain a node public key of the first service node (that is, a node public key corresponding to the node private key of the first service node), and check and sign the first signature information based on the node public key of the first service node, so as to obtain a first signature checking result. Further, the consensus node may receive the data credit request when the first signature verification result indicates that the signature verification is successful.
For ease of understanding, please refer to fig. 8, and fig. 8 is a schematic view of a scenario in which a data liquidation request is received according to an embodiment of the present application. The service node 80a shown in fig. 8 may be a first service node that sends a data accounting request, and the service node 80a may be any one of the nodes in the service network 100a shown in fig. 1, for example, the node 110 a; the consensus node 80c shown in fig. 8 may be a consensus node that receives a data credit request, and the consensus node 80c may be any one of the nodes in the core consensus network 100c shown in fig. 1, for example, the node 120 a; the proxy node 80b shown in fig. 8 may be used for network isolation between the service network and the core consensus network, and the proxy node 80b may be the proxy node 100b shown in fig. 1.
As shown in fig. 8, before the service node 80a sends the data clearing request to the proxy node 80b, the service node 80a may sign the data clearing request based on the node private key of the service node 80a, and obtain signature information (i.e., first signature information) corresponding to the data clearing request. It can be understood that the service node 80a may perform hash calculation on the data clearing request by using a hash algorithm, so as to obtain the summary information h of the data clearing request, and perform digital signature on the summary information h based on the node private key of the service node 80a, so as to obtain signature information corresponding to the data clearing request. Further, the service node 80a may send data inventory request and signature information to the proxy node 80 b.
As shown in fig. 8, when receiving the data clearing request and the signature information, the agent node 80b may obtain the system public key of the consensus network, and encrypt the data clearing request and the signature information through the system public key of the consensus network to obtain encrypted data information (i.e., the first encrypted data information). Further, the proxy node 80b may forward the encrypted data information to the consensus node 80 c.
As shown in fig. 8, when receiving the encrypted data information, the consensus node 80c may obtain a system private key of the consensus network, and perform decryption processing on the encrypted data information through the system private key of the consensus network to obtain a data clearing request and signature information. Further, the consensus node 80c may obtain the node public key of the service node 80a, and check the signature information based on the node public key of the service node 80a to obtain a signature check result (i.e., a first signature check result). The consensus node 80c may check the digital signature in the signature information based on the node public key of the service node 80a to obtain the digest information H of the data clearing request, and perform hash calculation on the received data clearing request based on the hash algorithm used by the service node 80a, so as to obtain the digest information H of the data clearing request, and further compare the digest information H obtained by checking the signature with the digest information H obtained by hash calculation to obtain a signature checking result.
When the summary information H is the same as the summary information H, the signature verification result indicates that the signature verification of the consensus node 80c is successful; when the summary information H is different from the summary information H, the signature verification result indicates that the signature verification of the consensus node 80c fails. It can be understood that, when the signature verification result indicates that the signature verification fails, the common node 80c may refuse to receive the data clearing request sent by the service node 80 a; when the result of the signature verification indicates that the signature verification is successful, the common node 80c may receive the data credit request sent by the service node 80 a.
Optionally, before the service node 80a sends the data clearing request and the signature information to the agent node 80b, the node public key of the agent node 80b may be obtained, the data clearing request and the signature information are encrypted by the node public key of the agent node 80b to obtain the encryption request information, and the encryption request information is sent to the agent node 80 b. Thus, when the agent node 80b receives the encryption request information, the encryption request information can be decrypted by the node private key of the agent node 80b to obtain the data clearing request and the signature information, and then the system public key of the consensus network is obtained to execute the subsequent steps.
Step S204, the consensus node determines (N-M) blocks from the block height M to the block height N on a block chain based on the data sorting request, acquires a block to be processed in the descending direction of the block heights of the (N-M) blocks, and performs block identification on the block to be processed to obtain a block identification result;
alternatively, it is understood that when one block is included in the (N-M) blocks, the consensus node may determine the liquidation data for returning to the consensus node based on the block type of the one block.
For a specific process of the consensus node performing block identification on the to-be-processed block, reference may be made to the description of step S102 in the embodiment corresponding to fig. 3, which will not be repeated herein.
Step S205, if the block identification result indicates that the block to be processed is the first exclusive block associated with the first service node, the consensus node obtains the block anchoring information in the first exclusive block, locates the block associated with the first service node among the (N-M) blocks through the block anchoring information, and determines the located block as an anchored locating block;
wherein the block height of the anchor positioning block is smaller than the block height of the block to be processed, and the blocks between the anchor positioning block and the block to be processed (i.e. the traffic filtering blocks) are the blocks which are skipped based on the block anchor information and are unrelated to the first traffic node. Optionally, when the block to be processed and the anchor positioning block are two adjacent blocks, and no service filtering block exists before the block to be processed and the anchor positioning block, the consensus node does not need to determine the sixth clearing data corresponding to the first service node based on the block type of the service filtering block.
For a specific process of the consensus node locating the anchor locating block through the block anchor information of the first exclusive block, reference may be made to the description of step S103 in the embodiment corresponding to fig. 3, which will not be described herein again.
Step S206, the consensus node determines first clearing data for returning to the first service node based on the block type of the anchoring positioning block, and returns the first clearing data to the first service node through the proxy node;
it should be understood that the block identification and block anchoring (i.e. positioning to the anchor positioning block by the block anchoring information in the first exclusive block type) in the embodiments of the present application may be performed asynchronously or synchronously. When the block identification and the block anchoring are performed asynchronously, the consensus node may obtain the blocks to be processed in the block height decreasing direction of the (N-M) blocks, perform the block identification on each block to be processed in the (N-M) blocks, obtain the block type of each block to be processed in the (N-M) blocks, and determine the score data to be returned to the first service node based on the block type of each block to be processed.
Optionally, when the block identification and the block anchoring are performed synchronously, the common identification node may obtain the block to be processed in the block height decreasing direction of the (N-M) blocks, perform the block identification on the obtained block to be processed, obtain the block type of the block to be processed, and determine the score clearing data of the block to be processed based on the block type of the block. Further, the common node may obtain a new block to be processed from the (N-M) blocks based on the block type of the block to be processed, so as to perform block identification on the obtained new block to be processed, and then perform the subsequent steps same as those of the block to be processed on the new block to be processed until the obtained latest block to be processed is the block M or the block with the block height smaller than the block M.
For convenience of understanding, please refer to fig. 9a, and fig. 9a is a schematic view illustrating a scenario for locating an exclusive block according to an embodiment of the present application. The consensus node in this embodiment may determine the (N-M) blocks shown in fig. 9a based on the data credit request sent by the first service node, where the (N-M) blocks may be 4 blocks, and the 4 blocks may specifically include block Q1, block Q2, block Q3, and block Q4. The block Q1 may be the block (M +1), and the block Q4 may be the block N.
It is to be understood that the consensus node may first obtain a first pending block from among the blocks Q1, … and Q4, where the first pending block may be the pending block 92a, the pending block 92a may be the block Q4, and when it is determined that the pending block 92a is the first exclusive block, the consensus node may locate an anchor positioning block from among the (N-M) blocks based on the block anchor information in the first exclusive block, where the anchor positioning block may be the anchor positioning block 92b, and the anchor positioning block 92b may be the block Q1. At this time, the consensus node may determine the block type of the anchor positioning block 92b, and obtain the score data corresponding to the anchor positioning block 92b based on the block type of the anchor positioning block 92 b. Meanwhile, the consensus node may also obtain the score data corresponding to the to-be-processed tile 92a based on the tile type of the to-be-processed tile 92a, that is, directly use the tile Q4 as the score data 91a corresponding to the to-be-processed tile 92 a.
Block Q1 may be a block associated with the first service node, i.e., a first type of exclusive block or a first type of non-exclusive block. When the block Q1 is a first-type exclusive block, the consensus node may obtain first sub-score data based on the block Q1, and when the block Q1 is a first-type non-exclusive block, the consensus node may obtain second sub-score data based on the block Q1, and further use the first sub-score data or the second sub-score data as score data corresponding to the block Q1.
As shown in fig. 9a, when the anchor positioning block 92b is a first type of exclusive block (i.e., exclusive block), the consensus node may directly use the block Q1 as the score data 91b (i.e., first sub-score data) corresponding to the anchor positioning block 92 b. It will be appreciated that the consensus node may return the score data 91a and score data 91b to the first service node via the proxy node, respectively, when the score data 91a and score data 91b are obtained, respectively. Optionally, when obtaining the score clearing data 91a and the score clearing data 91b respectively, the consensus node may also merge the score clearing data 91a and the score clearing data 91b as all score clearing data, and return the all score clearing data to the proxy node, so that the proxy node forwards the all score clearing data to the first service node.
For easy understanding, please refer to fig. 9b, and fig. 9b is a schematic view illustrating a scenario for locating a normal block according to an embodiment of the present application. Fig. 9b is another execution flow corresponding to fig. 9a, where the (N-M) blocks shown in fig. 9b are the (N-M) blocks shown in fig. 9a, and as shown in fig. 9b, the block Q1 may include a block header and a block body, and the block body may include a plurality of transaction data, where the number of the transaction data in the block body is 4 for example, and the 4 transaction data may include transaction Y1, transaction Y2, transaction Y3, and transaction Y4. Wherein transaction Y1 and transaction Y2 may be transaction data associated with the first service node, which transaction Y1 and transaction Y2 may be collectively referred to as transaction data 93 a; transaction Y3 and transaction Y4 may be transaction data unrelated to the first service node (e.g., transaction data associated with the second service node), which may be collectively referred to as transaction data 93b, transaction Y3 and transaction Y4.
As shown in fig. 9b, when the anchor positioning block 92b is a first non-exclusive block (i.e., a normal block), the consensus node may use the block header of the block Q1, the mercker certification information corresponding to the transaction data 93a, and the transaction data 93a (i.e., the transaction Y1 and the transaction Y2) as the liquidation data 91c (i.e., the second sub-liquidation data) corresponding to the anchor positioning block 92 b. It will be appreciated that the consensus node may return the score data 91a and score data 91c to the first service node via the proxy node, respectively, when the score data 91a and score data 91c are obtained, respectively. Optionally, when obtaining the score clearing data 91a and the score clearing data 91c respectively, the consensus node may also merge the score clearing data 91a and the score clearing data 91c as all score clearing data, and return the all score clearing data to the proxy node, so that the proxy node forwards the all score clearing data to the first service node.
Step S207, the first service node receives the first clearing data returned by the consensus node through the proxy node.
It can be understood that the consensus node can sign all the liquidity data through a node private key of the consensus node to obtain second signature information. Further, the consensus node may return the second encrypted data information to the first service node through the proxy node. And the second encrypted data information is obtained by encrypting all the clearing data and the second signature information through a system public key of the service network by the proxy node. The second encrypted data information is used for instructing the first service node to obtain a system private key of the service network (namely, a system private key corresponding to a system public key of the service network), and the second encrypted data information is decrypted by the system private key of the service network to obtain all the liquidation data and the second signature information. The total clearing data and the second signature information are used for indicating the first service node to obtain a node public key of the consensus node (namely, a node public key corresponding to a node private key of the consensus node), and the second signature information is verified based on the node public key of the consensus node to obtain a second verification result. And the second signature verification result is used for indicating the first service node to receive the second encrypted data information when the first service node confirms that the second signature verification result indicates that signature verification is successful.
It should be understood that, for a specific process of signing all the liquidation data by the consensus node, reference may be made to the description of signing the data liquidation request by the first service node, which will not be described in detail. It should be understood that, for a specific process in which the first service node performs signature verification on the second signature information based on the node public key of the consensus node, reference may be made to the description that the consensus node performs signature verification on the first signature information based on the node public key of the first service node, which will not be described herein again.
And the consensus node can directly send all the liquidation data and the second signature information to the agent node. Optionally, before sending all the score clearing data and the second signature information to the agent node, the consensus node may obtain a node public key of the agent node, encrypt all the score clearing data and the second signature information through the node public key of the agent node to obtain encrypted score clearing data, and send the encrypted score clearing data to the agent node. Therefore, when the proxy node receives the encrypted clearing data, the proxy node can decrypt the encrypted clearing data through the node private key of the proxy node to obtain all the clearing data and second signature information, and further obtain the system public key of the service network to execute the subsequent steps.
It can be understood that the credit data returned by the consensus node to the first service node can enable the first service node to store the minimum set of block and transaction data required by the first service node as much as possible, and simultaneously ensure the data privacy isolation and the data credit efficiency.
It can be understood that, when the clearing data received by the first service node includes the third clearing data, the first service node may verify the third clearing data based on the first transaction data, the first merkel certification information and the block head of the first non-exclusive block in the third clearing data. Specifically, the first service node may determine the first tree root to be compared, which corresponds to the first non-exclusive block, based on the first transaction hash value corresponding to the first transaction data and the path hash value in the merkel certification information. Further, the first service node may obtain the verification result of the non-exclusive block of the first type based on the root of the first tree to be compared and a root of a merkel tree (e.g., a first merkel tree root) in a block header of the non-exclusive block of the first type. Further, if the verification result indicates that the verification is successful, the first service node may synchronize the block header of the first type of non-exclusive block to the block header chain of the first service node. If the first root to be compared is the same as the first Merck root, the verification result indicates that the verification is successful.
It can be understood that, when the credit data received by the first service node includes the fifth credit data, the first service node may directly authenticate the first type exclusive block. Specifically, the first service node may determine, based on the transaction hash value corresponding to the transaction data in the first type of exclusive block, a second tree root to be compared, which corresponds to the first type of exclusive block. Further, the first service node may obtain a verification result of the first type exclusive block based on the second tree root to be compared and a merkel tree root (e.g., a second merkel tree root) in a block header of the first type exclusive block. Further, if the verification result indicates that the verification is successful, the first service node may synchronize the block header of the first type exclusive block to the block header chain of the first service node. And if the second tree root to be compared is the same as the second Mercker tree root, the verification result indicates that the verification is successful.
It can be understood that, when the credit data received by the first service node includes the second credit data, the first service node may determine the second type of exclusive block after data hiding as a hidden block header, and then synchronize the hidden block header to the block header chain of the first service node.
It can be understood that, when the score clearing data received by the first service node includes the fourth score data, the first service node may synchronize the block header of the second type of exclusive block to the block header chain of the first service node.
For easy understanding, please refer to fig. 10, fig. 10 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. 10, the service layer, the routing agent layer and the core consensus network layer in the embodiment of the present application constitute an entire blockchain service system. The blockchain shown in fig. 10 is a target blockchain maintained by the core consensus network layer. For convenience of understanding, 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 layer is in the witness network, and can submit service operation interaction to the core consensus network layer, and a service node (e.g., a first service node) in the service layer may include a terminal device corresponding to an electronic tax bureau, a terminal device corresponding to an enterprise user, and a terminal device corresponding to a consumer (i.e., a consumer). The electronic tax office may refer to a local tax office in a private network of the tax office, the enterprise user may be an invoicing facilitator, an reimbursement facilitator, or a retail enterprise (e.g., KA enterprise, i.e., large retail customer and key retail customer enterprise) in a public cloud, and the consumer user may be a payment facilitator, a circulation facilitator, or a retail enterprise in a private cloud. For example, the ticket transfer service executed by the first service node (e.g., terminal device a corresponding to the consuming user) may be: and transferring the electronic bill (for example, the electronic bill X) obtained when the consumer purchases the equipment to the corresponding terminal device B of the enterprise where the consumer is located. Of course, a second service node may also be included in the service layer. For example, two invoicers (e.g., employee 1 and employee 2) of two companies, invoicing on respective terminal devices produces some transaction data. For example, employee 1 may perform a transaction using terminal device a1 to generate corresponding transaction data, and employee 2 may perform a transaction using terminal device a2 to generate corresponding transaction data.
The proxy node in the routing proxy layer may be used for network isolation between the service layer and the core consensus network layer, and the proxy node may have a point-to-point service (i.e., P2P service), a routing service, a certificate cache, and an authentication service. It is understood that the point-to-point service refers to a service in the P2P network, and based on a specific network protocol, a central node is not required between network nodes in the P2P network to maintain the network state, but each node maintains the node state of the whole network or the connection state of its neighboring nodes through broadcast interaction with the neighboring nodes. Routing services are basic functions that nodes have and may be used for communication between nodes. The Certificate in the Certificate cache may be referred to as 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 the transaction format, node validity, etc. of the received information. It can be understood that, in the embodiment of the present application, the proxy node may forward the data clearing request sent by the first service node in the service layer to the consensus node in the core consensus network layer, and may also forward the clearing data returned by the consensus node in the core consensus network layer to the first service node in the service layer. During the forwarding process, the proxy node may perform encryption processing on the forwarded data.
The consensus node (i.e. the accounting node) in the core consensus network layer can be a trusted node (i.e. a TrustSQL node) in the tax private network. It will be appreciated that each consensus node has the ability to wrap blocks, i.e., transaction data forwarded by the proxy node can be verified and added to the transaction pool (i.e., the cache shown in fig. 10) of the consensus node when the verification is successful. Further, the consensus node may pack the transaction data in its own transaction pool into blocks, so as to successfully write the blocks into the target block chain in the core consensus network layer. In addition, the consensus node may determine, on receipt of a data inventory request forwarded by the proxy node, inventory data on the target blockchain for return to the first service node.
Therefore, when the consensus node receives a data clearing request sent by the first service node, the embodiment of the present application may determine (N-M) blocks to be subjected to data clearing on a block chain maintained locally, and further obtain the block to be processed in the direction of decreasing block height of the (N-M) blocks, so that when the consensus node determines that the block to be processed is an exclusive block (i.e., a first-type exclusive block) associated with the first service node, the block (here, referred to as a service filtering block) unrelated to the first service node may be quickly skipped through anchor rule information (i.e., block anchor information) and cleared to a previous block (here, referred to as an anchor positioning block) associated with the first service node itself, and further, the efficiency of data clearing may be improved. It should be understood that the service filtering blocks herein may include normal blocks unrelated to the first service node (i.e., non-exclusive blocks of the second type) and exclusive blocks unrelated to the first service node (i.e., exclusive blocks of the second type), and the anchor positioning blocks herein may include normal blocks related to the first service node (i.e., non-exclusive blocks of the first type) and exclusive blocks related to the first service node (i.e., exclusive blocks of the first type), where transaction data in the exclusive blocks of the first type are related to the first service node, so that the embodiments of the present application may improve the efficiency of data sorting while achieving privacy isolation of data in other blocks unrelated to the first service node.
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 10 may be a computer program (including program code) running on a computer apparatus, for example, the transaction data processing device 10 is an application software; the transaction data processing device 10 may be used to perform the corresponding steps in the methods provided by the embodiments of the present application. As shown in fig. 11, the transaction data processing apparatus 10 may operate in a consensus node in a core consensus network, which may be the consensus node 20c in the embodiment corresponding to fig. 2. The transaction data processing device 10 may include: a request receiving module 101, a block obtaining module 102, a block positioning module 103, and a first returning module 104; further, the transaction data processing device 10 may further include: a data hiding module 105, a second returning module 106, a transaction determining module 107, a third returning module 108, a fourth returning module 109, a first determining module 110, a second determining module 111, and a data returning module 112;
a request receiving module 101, configured to receive a data clearing request forwarded by a first service node in a service network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request carries a block height M and a block height N; the block height M is the maximum block height on the block head chain stored by the first service node; the block height N is the maximum block height on the block chain maintained by the common node; n is a positive integer; m is a positive integer less than N;
the block obtaining module 102 is configured to determine (N-M) blocks from a block height M to a block height N on a block chain based on the data sorting request, obtain a block to be processed in a block height decreasing direction of the (N-M) blocks, and perform block identification on the block to be processed to obtain a block identification result;
the block acquiring module 102 includes: a tile determining unit 1021, a tile identifying unit 1022, a first identifying unit 1023, a first adding unit 1024; optionally, the block acquiring module 102 may further include: a second adding unit 1025, a second identifying unit 1026, a third adding unit 1027, a fourth adding unit 1028;
a block determining unit 1021, configured to determine (N-M) blocks from a block height M to a block height N on the block chain based on the data sorting request, and mark the block identification statuses of the determined (N-M) blocks as statuses to be identified;
a block identification unit 1022 for identifying, among the (N-M) blocks, a block having the maximum block height and identifying a state to be identified as a block to be processed, the block identification information in the block to be processed;
a first identifying unit 1023, configured to, when the block identification information is identified as the first type of block identification information, use the block type of the to-be-processed block as the first block type, mark the block identification state of the to-be-processed block having the first block type as an identified state from the to-be-identified state, use the to-be-processed block having the first block type and identified with the identified state as an exclusive block to be classified, and obtain node identification information in the exclusive block to be classified;
a first adding unit 1024, configured to determine, if the obtained node identification information is a first class node identification associated with the first service node, the exclusive block to be classified as a first class exclusive block associated with the first service node, take the first class exclusive block as a first exclusive identification result, and add the first exclusive identification result to the block identification result corresponding to the block to be processed; the first exclusive identification result is used for executing the step of acquiring the block anchoring information in the first type exclusive block when the block to be processed is the first type exclusive block.
Wherein the service network comprises a second service node;
optionally, the second adding unit 1025 is configured to, if the obtained node identification information is a second class node identification associated with a second service node, determine the exclusive block to be classified as a second class exclusive block unrelated to the first service node, take the second class exclusive block as a second exclusive recognition result, and add the second exclusive recognition result to the block recognition result corresponding to the block to be processed.
Optionally, the second identifying unit 1026 is configured to, when the block identification information is identified as the second type of block identification information, use the block type of the block to be processed as the second block type, mark the block identification state of the block to be processed having the second block type as the identified state from the to-be-identified state, use the block to be processed having the second block type and identified with the identified state as the non-exclusive block to be classified, and filter the transaction data associated with the first service node in the non-exclusive block to be classified;
a third adding unit 1027, configured to determine the non-exclusive block to be classified as a first type of non-exclusive block associated with the first service node if the transaction data associated with the first service node is screened from the non-exclusive blocks to be classified, take the first type of non-exclusive block as a first non-exclusive identification result, and add the first non-exclusive identification result to the block identification result corresponding to the block to be processed.
Optionally, the fourth adding unit 1028 is configured to, if the transaction data associated with the first service node is not screened from the to-be-categorized non-exclusive area blocks, determine the to-be-categorized non-exclusive area blocks as a second type of non-exclusive area blocks unrelated to the first service node, use the second type of non-exclusive area blocks as a second non-exclusive identification result, and add the second non-exclusive identification result to the area identification result corresponding to the to-be-processed area block.
For a specific implementation manner of the block determining unit 1021, the block identifying unit 1022, the first identifying unit 1023, the first adding unit 1024, the second adding unit 1025, the second identifying unit 1026, the third adding unit 1027, and the fourth adding unit 1028, reference may be made to the description of step S102 in the embodiment corresponding to fig. 3, which will not be described again here.
A block positioning module 103, configured to, if the block identification result indicates that the block to be processed is a first type of exclusive block associated with the first service node, obtain block anchor information in the first type of exclusive block, position the block associated with the first service node among the (N-M) blocks through the block anchor information, and determine the positioned block as an anchor positioning block; the block height of the anchoring positioning block is smaller than that of the block to be processed, and the block between the anchoring positioning block and the block to be processed is a block which is skipped based on the block anchoring information and is irrelevant to the first service node;
a first returning module 104, configured to determine, based on the block type of the anchor positioning block, first clearing data to be returned to the first service node, and return the first clearing data to the first service node through the proxy node.
Wherein the first returning module 104 comprises: a first comparing unit 1041, a second comparing unit 1042, a data returning unit 1043;
a first comparing unit 1041, configured to, if the block type of the anchor positioning block is the same as the block type of the first exclusive block, use the anchor positioning block as first sub-liquidity data of the first service node;
a second comparing unit 1042, configured to obtain, if the block type of the anchor positioning block is different from the block type of the first exclusive block, key service data information associated with the first service node in the anchor positioning block, and use the obtained key service data information as second sub-liquidation data of the first service node;
a data returning unit 1043, configured to use the first sub-score data or the second sub-score data as the first score data of the first service node, and return the first score data to the first service node through the proxy node.
For specific implementation manners of the first comparing unit 1041, the second comparing unit 1042, and the data returning unit 1043, reference may be made to the description of step S104 in the embodiment corresponding to fig. 3, which will not be described herein again.
Optionally, the data hiding module 105 is configured to hide the data of the second type of exclusive block based on the second type of exclusive block indicated by the second exclusive identification result if the block identification result includes the second exclusive identification result, so as to obtain a block hash of the second type of exclusive block and a parent block hash of the second type of exclusive block;
the second returning module 106 uses the block hash of the second exclusive block and the parent block hash of the second exclusive block as the second credit data of the first service node, and returns the second credit data to the first service node through the proxy node.
Optionally, the transaction determining module 107 is configured to, if the block identification result includes a first non-exclusive identification result, use transaction data associated with the first service node in the first non-exclusive block as first transaction data based on the first non-exclusive block indicated by the first non-exclusive identification result;
the third returning module 108 is configured to obtain a block header of the first non-exclusive block and first tacher certification information corresponding to the first transaction data, use the first transaction data, the first tacher certification information, and the block header of the first non-exclusive block as third clearing data of the first service node, and return the third clearing data to the first service node through the proxy node.
Optionally, the fourth returning module 109 is configured to, if the block identification result includes the second non-exclusive identification result, based on the second type of non-exclusive block indicated by the second non-exclusive identification result, use a block header of the second type of non-exclusive block as fourth clearing data of the first service node, and return the fourth clearing data to the first service node through the proxy node.
Optionally, the first determining module 110 is configured to use the first type exclusive block as fifth credit clearing data of the first service node;
a second determining module 111, configured to, in the (N-M) blocks, use a block between the anchor positioning block and the first type exclusive block as a service filtering block unrelated to the first service node, and determine, based on a block type of the service filtering block, sixth liquidation data for returning to the first service node;
and a data returning module 112, configured to return the fifth clearing data and the sixth clearing data to the first service node through the proxy node.
For specific implementation manners of the request receiving module 101, the block obtaining module 102, the block positioning module 103, the first returning module 104, the data hiding module 105, the second returning module 106, the transaction determining module 107, the third returning module 108, the fourth returning module 109, the first determining module 110, the second determining module 111, and the data returning module 112, reference may be made to the description of step S101 to step S104 in the embodiment corresponding to fig. 3, and details thereof will not be described here. In addition, the beneficial effects of the same method are not described in detail.
Further, please refer to fig. 12, wherein fig. 12 is a schematic structural diagram of a transaction data processing apparatus according to an embodiment of the present application. The transaction data processing device 20 may be a computer program (including program code) running on a computer apparatus, for example, the transaction data processing device 20 is an application software; the transaction data processing device 20 may be used to perform the corresponding steps in the methods provided by the embodiments of the present application. As shown in fig. 12, the transaction data processing device 20 may operate in a first service node in a service network, and the first service node may be the service node 20a in the embodiment corresponding to fig. 2. The transaction data processing device 20 may include: a request generating module 201, a request sending module 202 and a data receiving module 203;
a request generating module 201, configured to obtain a block height M and a block height N, and generate a data sorting request based on the block height M and the block height N; the block height M is the maximum block height on the block head chain stored by the first service node; the block height N is the maximum block height on a block chain maintained by a consensus node in the core consensus network; n is a positive integer; m is a positive integer less than N;
a request sending module 202, configured to send a data clearing request to a consensus node through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request is used for indicating the consensus node to acquire the block to be processed in the descending direction of the block heights of the (N-M) blocks from the block height M to the block height N of the block chain, and performing block identification on the block to be processed to obtain a block identification result;
the data receiving module 203 is used for receiving first clearing data returned by the consensus node through the agent node; the first liquidity data is determined by the consensus node based on the block type of the anchor positioning block; the anchor positioning block is positioned in the (N-M) blocks by the common node through the block anchor information; the block anchoring information is obtained after the consensus node determines that the block identification result indicates that the block to be processed is a first exclusive block associated with the first service node; the block height of the anchor positioning block is smaller than the block height of the block to be processed, and the block between the anchor positioning block and the block to be processed is a block that is skipped based on the block anchor information and is unrelated to the first service node.
For specific implementation manners of the request generating module 201, the request sending module 202, and the data receiving module 203, reference may be made to the description of step S201 to step S207 in the embodiment corresponding to fig. 7, which will not be 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 computer device according to an embodiment of the present application. As shown in fig. 13, the computer apparatus 1000 may include: the processor 1001, the network interface 1004, and the memory 1005, and the computer apparatus 1000 may further include: a user interface 1003, and at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display) and a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a standard wireless interface. Optionally, the network interface 1004 may include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. Optionally, the memory 1005 may also be at least one memory device located remotely from the processor 1001. As shown in fig. 13, a memory 1005, which is a kind of computer-readable storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.
In the computer device 1000 shown in fig. 13, the network interface 1004 may provide a network communication function; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005.
It should be understood that the computer device 1000 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 device 10 in the embodiment corresponding to fig. 11 or the transaction data processing device 20 in the embodiment corresponding to fig. 12, 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, and the computer-readable storage medium stores the aforementioned computer program executed by the transaction data processing apparatus 10 or the transaction data processing apparatus 20, 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, so that details 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 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.
Further, it should be noted that: embodiments of the present application also provide a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor can execute the computer instruction, so that the computer device executes the description of the transaction data processing method in the embodiment corresponding to fig. 3 or fig. 7, which is described above, 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 computer program product or the computer program referred to in the present application, 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 can include the processes of the embodiments of the methods described above when the computer program is executed. 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 (15)

1. A transaction data processing method, performed by a consensus node in a core consensus network, comprising:
receiving a data clearing request forwarded by a first service node in a service network through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request carries a block height M and a block height N; the block height M is the maximum block height over a chain of block headers stored by the first service node; the block height N is the maximum block height on a block chain maintained by the common node; n is a positive integer; m is a positive integer less than N;
determining (N-M) blocks from the block height M to the block height N on the block chain based on the data sorting request, acquiring a block to be processed in the descending direction of the block height of the (N-M) blocks, and performing block identification on the block to be processed to obtain a block identification result;
if the block identification result indicates that the block to be processed is a first type exclusive block associated with the first service node, acquiring block anchoring information in the first type exclusive block, positioning the block associated with the first service node in the (N-M) blocks through the block anchoring information, and determining the positioned block as an anchored positioning block; the anchor positioning block has a block height less than a block height of the to-be-processed block, and blocks between the anchor positioning block and the to-be-processed block are skipped blocks unrelated to the first service node based on the block anchor information;
and determining first clearing data for returning to the first service node based on the block type of the anchoring positioning block, and returning the first clearing data to the first service node through the proxy node.
2. The method according to claim 1, wherein said determining (N-M) blocks from the block height M to the block height N on the block chain based on the data sorting request, obtaining a block to be processed in a decreasing direction of the block heights of the (N-M) blocks, and performing block identification on the block to be processed to obtain a block identification result comprises:
determining (N-M) blocks from the block height M to the block height N on the block chain based on the data clearing request, and marking the block identification states of the determined (N-M) blocks as to-be-identified states;
identifying block identification information in a block to be processed, which identifies a state to be identified and has a maximum block height, among the (N-M) blocks, as the block to be processed;
when the block identification information is identified to be first class block identification information, taking the block type of the block to be processed as a first block type, marking the block identification state of the block to be processed with the first block type as an identified state from the to-be-identified state, taking the block to be processed with the first block type and identified with the identified state as an exclusive block to be classified, and acquiring node identification information in the exclusive block to be classified;
if the acquired node identification information is a first class node identification associated with the first service node, determining the exclusive block to be classified as a first class exclusive block associated with the first service node, taking the first class exclusive block as a first exclusive identification result, and adding the first exclusive identification result to a block identification result corresponding to the block to be processed; the first exclusive identification result is used for executing the step of acquiring the block anchoring information in the first type of exclusive block when the block to be processed is the first type of exclusive block.
3. The method of claim 2, wherein the service network comprises a second service node;
the method further comprises the following steps:
and if the acquired node identification information is a second-class node identification associated with the second service node, determining the exclusive block to be classified as a second-class exclusive block irrelevant to the first service node, taking the second-class exclusive block as a second exclusive identification result, and adding the second exclusive identification result to a block identification result corresponding to the block to be processed.
4. The method of claim 3, further comprising:
if the block identification result comprises the second exclusive identification result, hiding data of the second exclusive block based on the second exclusive block indicated by the second exclusive identification result to obtain a block hash of the second exclusive block and a parent block hash of the second exclusive block;
and taking the block hash of the second exclusive block and the parent block hash of the second exclusive block as second clearing data of the first service node, and returning the second clearing data to the first service node through the proxy node.
5. The method of claim 2, further comprising:
when the block identification information is identified to be second-class block identification information, taking the block type of the block to be processed as a second block type, marking the block identification state of the block to be processed with the second block type as an identified state from the to-be-identified state, taking the block to be processed with the second block type and identified with the identified state as a non-exclusive block to be classified, and screening transaction data associated with the first service node in the non-exclusive block to be classified;
if transaction data associated with the first service node is screened from the to-be-classified non-exclusive blocks, determining the to-be-classified non-exclusive blocks as first non-exclusive blocks associated with the first service node, taking the first non-exclusive blocks as first non-exclusive identification results, and adding the first non-exclusive identification results to block identification results corresponding to the to-be-processed blocks.
6. The method of claim 5, further comprising:
if the block identification result comprises the first non-exclusive identification result, taking transaction data associated with the first service node in the first non-exclusive block as first transaction data based on the first non-exclusive block indicated by the first non-exclusive identification result;
and acquiring a block head of the first non-exclusive block and first Mercker certification information corresponding to the first transaction data, taking the first transaction data, the first Mercker certification information and the block head of the first non-exclusive block as third clearing data of the first service node, and returning the third clearing data to the first service node through the proxy node.
7. The method of claim 5, further comprising:
if the transaction data associated with the first service node is not screened from the to-be-classified non-exclusive blocks, determining the to-be-classified non-exclusive blocks as second non-exclusive blocks irrelevant to the first service node, taking the second non-exclusive blocks as second non-exclusive identification results, and adding the second non-exclusive identification results to block identification results corresponding to the to-be-processed blocks.
8. The method of claim 7, further comprising:
and if the block identification result comprises the second non-exclusive identification result, based on the second non-exclusive block indicated by the second non-exclusive identification result, taking the block head of the second non-exclusive block as fourth clearing data of the first service node, and returning the fourth clearing data to the first service node through the proxy node.
9. The method of claim 1, wherein determining first credit data for returning to the first service node based on the block type of the anchor positioning block, returning the first credit data to the first service node through the proxy node, comprises:
if the block type of the anchor positioning block is the same as that of the first exclusive block, taking the anchor positioning block as first sub-liquidity data of the first service node;
if the block type of the anchoring positioning block is different from the block type of the first exclusive block, acquiring key service data information associated with the first service node in the anchoring positioning block, and taking the acquired key service data information as second sub-liquidation data of the first service node;
and taking the first sub-liquidation data or the second sub-liquidation data as the first liquidation data of the first service node, and returning the first liquidation data to the first service node through the proxy node.
10. The method of claim 1, further comprising:
taking the first exclusive block as fifth clearing data of the first service node;
determining, among the (N-M) tiles, sixth credit data for return to the first service node based on a tile type of the service filter tile, taking a tile between the anchor positioning tile and the first type exclusive tile as a service filter tile unrelated to the first service node;
and returning the fifth clearing data and the sixth clearing data to the first service node through the proxy node.
11. A method of transaction data processing, the method being performed by a first service node in a service network, comprising:
acquiring a block height M and a block height N, and generating a data clearing request based on the block height M and the block height N; the block height M is the maximum block height over a chain of block headers stored by the first service node; the block height N is the maximum block height on a block chain maintained by a consensus node in a core consensus network; n is a positive integer; m is a positive integer less than N;
sending the data clearing request to the consensus node through a proxy node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request is used for indicating the common identification node to acquire a block to be processed in the descending direction of the block heights of (N-M) blocks from the block height M to the block height N of the block chain, and carrying out block identification on the block to be processed to obtain a block identification result;
receiving first clearing data returned by the consensus node through the agent node; the first liquidation data is determined by the consensus node based on a block type of an anchor positioning block; the anchor positioning block is positioned in the (N-M) blocks by the common node through block anchor information; the block anchoring information is obtained after the consensus node determines that the block identification result indicates that the block to be processed is a first type of exclusive block associated with the first service node; the anchor positioning block has a block height less than a block height of the to-be-processed block, and blocks between the anchor positioning block and the to-be-processed block are skipped blocks unrelated to the first traffic node based on the block anchor information.
12. A transaction data processing apparatus, comprising:
the request receiving module is used for receiving a data clearing request forwarded by a first service node in a service network through a proxy node; the agent node is used for carrying out network isolation on a core consensus network and the service network; the data sorting request carries a block height M and a block height N; the block height M is the maximum block height over a chain of block headers stored by the first service node; the block height N is the maximum block height on a block chain maintained by the common node; n is a positive integer; m is a positive integer less than N;
a block obtaining module, configured to determine, on the basis of the data sorting request, N-M blocks from the block height M to the block height N on the block chain, obtain a block to be processed in a direction in which the block heights of the N-M blocks decrease, and perform block identification on the block to be processed to obtain a block identification result;
a block positioning module, configured to, if the block identification result indicates that the block to be processed is a first type of exclusive block associated with the first service node, obtain block anchor information in the first type of exclusive block, position the block associated with the first service node among the (N-M) blocks through the block anchor information, and determine the positioned block as an anchor positioning block; the anchor positioning block has a block height less than a block height of the to-be-processed block, and blocks between the anchor positioning block and the to-be-processed block are skipped blocks unrelated to the first service node based on the block anchor information;
a first returning module, configured to determine, based on the block type of the anchor positioning block, first clearing data to be returned to the first service node, and return the first clearing data to the first service node through the proxy node.
13. A transaction data processing apparatus, comprising:
the request generation module is used for acquiring a block height M and a block height N and generating a data clearing request based on the block height M and the block height N; the block height M is the maximum block height on a block head chain stored by the first service node; the block height N is the maximum block height on a block chain maintained by a consensus node in a core consensus network; n is a positive integer; m is a positive integer less than N;
the request sending module is used for sending the data clearing request to the consensus node through the agent node; the agent node is used for carrying out network isolation on the core consensus network and the service network; the data sorting request is used for indicating the common identification node to acquire a block to be processed in the descending direction of the block heights of (N-M) blocks from the block height M to the block height N of the block chain, and carrying out block identification on the block to be processed to obtain a block identification result;
the data receiving module is used for receiving first clearing data returned by the consensus node through the agent node; the first liquidation data is determined by the consensus node based on a block type of an anchor positioning block; the anchor positioning block is positioned in the (N-M) blocks by the common node through block anchor information; the block anchoring information is obtained after the consensus node determines that the block identification result indicates that the block to be processed is a first type of exclusive block associated with the first service node; the anchor positioning block has a block height less than a block height of the to-be-processed block, and blocks between the anchor positioning block and the to-be-processed block are skipped blocks unrelated to the first traffic node based on the block anchor information.
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.
CN202110688386.XA 2021-06-21 2021-06-21 Transaction data processing method, device, equipment and medium Active CN113259130B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202110688386.XA CN113259130B (en) 2021-06-21 2021-06-21 Transaction data processing method, device, equipment and medium
CN202111088871.XA CN113765675B (en) 2021-06-21 2021-06-21 Transaction data processing method, device, equipment and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110688386.XA CN113259130B (en) 2021-06-21 2021-06-21 Transaction data processing method, device, equipment and medium

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202111088871.XA Division CN113765675B (en) 2021-06-21 2021-06-21 Transaction data processing method, device, equipment and medium

Publications (2)

Publication Number Publication Date
CN113259130A CN113259130A (en) 2021-08-13
CN113259130B true CN113259130B (en) 2021-09-14

Family

ID=77189135

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202111088871.XA Active CN113765675B (en) 2021-06-21 2021-06-21 Transaction data processing method, device, equipment and medium
CN202110688386.XA Active CN113259130B (en) 2021-06-21 2021-06-21 Transaction data processing method, device, equipment and medium

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202111088871.XA Active CN113765675B (en) 2021-06-21 2021-06-21 Transaction data processing method, device, equipment and medium

Country Status (1)

Country Link
CN (2) CN113765675B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115708118A (en) * 2021-08-18 2023-02-21 华为技术有限公司 Block chain generation method and device
CN114817229B (en) * 2022-06-21 2022-09-20 布比（北京）网络技术有限公司 Block chain based score clearing data processing method and block chain system

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190059491A (en) * 2017-11-23 2019-05-31 박동화 System and method for e-commerce with shared and distributed ledger coupled with outer storage devices
CN109409855B (en) * 2018-10-29 2022-03-22 合肥学院 Metablock and generation, identification and filtering method thereof
CN109714412B (en) * 2018-12-25 2021-08-10 深圳前海微众银行股份有限公司 Block synchronization method, device, equipment and computer readable storage medium
JP6821053B2 (en) * 2019-03-21 2021-01-27 アドバンスド ニュー テクノロジーズ カンパニー リミテッド Data quarantine in blockchain network
CN110473106A (en) * 2019-08-21 2019-11-19 腾讯科技（深圳）有限公司 A kind of method and relevant apparatus of trading processing
CN110602096B (en) * 2019-09-12 2021-07-13 腾讯科技（深圳）有限公司 Data processing method, device, storage medium and equipment in block chain network
CN110650189B (en) * 2019-09-20 2022-01-18 深圳供电局有限公司 Relay-based block chain interaction system and method
CN110888892B (en) * 2019-11-15 2023-06-16 腾讯科技（深圳）有限公司 Block synchronization method, device and storage medium
CN111309809A (en) * 2020-02-19 2020-06-19 财付通支付科技有限公司 Block header storage method and equipment thereof
CN111309711A (en) * 2020-03-13 2020-06-19 财付通支付科技有限公司 Cross-block-chain data migration method, device, equipment and storage medium
CN111416808B (en) * 2020-03-13 2021-04-13 财付通支付科技有限公司 Cross-block-chain data mutual storage method, device, equipment and storage medium
CN111966731A (en) * 2020-10-23 2020-11-20 支付宝(杭州)信息技术有限公司 Method and device for querying data in block chain system
CN113190622B (en) * 2021-03-16 2022-08-09 腾讯科技（深圳）有限公司 Data processing method, device, equipment and storage medium

Also Published As

Publication number Publication date
CN113765675A (en) 2021-12-07
CN113765675B (en) 2022-05-27
CN113259130A (en) 2021-08-13

Similar Documents

Publication Publication Date Title
CN112926982B (en) Transaction data processing method, device, equipment and storage medium
CN112685505B (en) Transaction data processing method and device, computer equipment and storage medium
CN112667749B (en) Data processing method, device, equipment and storage medium
CN111556120B (en) Data processing method and device based on block chain, storage medium and equipment
CN113421097B (en) Data processing method and device, computer equipment and storage medium
CN110839029B (en) Micro-service registration method and device
CN111291060B (en) Method, device and computer readable medium for managing blockchain nodes
CN112085504B (en) Data processing method and device, computer equipment and storage medium
JP6495346B2 (en) Information processing system
CN112287034B (en) Data synchronization method, equipment and computer readable storage medium
CN111597567B (en) Data processing method, data processing device, node equipment and storage medium
CN113259130B (en) Transaction data processing method, device, equipment and medium
CN111314067A (en) Block storage method and device, computer equipment and storage medium
AU2019380381A1 (en) Smart logistics management using blockchain
CN111488372A (en) Data processing method, device and storage medium
CN113518005B (en) Block consensus method, device, equipment and storage medium
CN113837760B (en) Data processing method, data processing device, computer equipment and storage medium
WO2019142884A1 (en) Block verification device, block verification method and program
US20220114276A1 (en) Controlling a data network with respect to a use of a distributed database
Muhtasim et al. Secure data transaction and data analysis of IOT devices using blockchain
WO2021172589A1 (en) Information processing system and program
CN117407437A (en) Block chain-based data processing method, equipment and readable storage medium
Selvaganesh et al. Secure data storage based on efficient auditing scheme
CN117131079A (en) Data processing method, device, equipment and medium based on block chain
CN117675216A (en) Data processing method and related equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40050033

Country of ref document: HK