A data processing method and device based on a layered chain network, equipment and medium

Abstract

The application discloses a data processing method and device based on a layered chain network, equipment and medium. The method comprises the following steps: acquiring a data positioning request for target service data sent by a service object; when the target data identifier of the target service data is acquired from the data positioning request, determining the first node mapping identifier of the first checking node in the ring mapping space; in the addressing direction, the target data identifier is subjected to data checking through the resource positioning table associated with the first node address of the first node mapping identifier, and the first data checking result is obtained; when the first data checking result indicates that the target data identifier is not contained in the synchronization data identifier, in the node routing list, the node mapping identifier closest to the target data identifier in the reverse direction of the addressing direction is taken as the second node mapping identifier, and the data positioning request is forwarded to the second checking node corresponding to the second node mapping identifier. By using the application, the checking efficiency of service data can be improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a data processing method, apparatus, device and medium based on a hierarchical blockchain network. Background Technology

[0002] Currently, blockchain systems can adopt a blockchain network built on a two-layer chain structure to form a layered structure of "business network - core consensus network", thereby improving the confidentiality and security of data on the blockchain.

[0003] The inventors discovered in practice that, under the hierarchical structure of a blockchain network, each business node in the network can only access business data relevant to itself, and cannot store all data in the blockchain network. Therefore, querying and verifying specific business data on any business node can be time-consuming. For example, if a user wants to verify the authenticity of certain business data (e.g., business data X) on the chain, since the user does not know the specific address where business data X is stored, they can randomly initiate a query on any business node in the network (e.g., business node 1). If business node 1 does not contain the business data X to be verified, they can initiate the same query on the next business node closer to business node 1 (e.g., business node 2), and so on, until a business node storing business data X is found to verify its authenticity. Clearly, this point-by-point verification method, in the worst case, requires searching all business nodes to obtain the required address. Especially when there are a large number of business nodes in the network, and nodes join or leave frequently, its addressing efficiency is low, resulting in low verification efficiency when checking business data. Summary of the Invention

[0004] This application provides a data processing method, apparatus, device, and medium based on a hierarchical chain network, which can improve the verification efficiency of business data by enhancing the addressing efficiency of verification nodes.

[0005] This application provides a data processing method based on a hierarchical blockchain network, which includes at least a verification network and a core consensus network. The verification network is deployed in the business network of the hierarchical blockchain network, which is independent of the core consensus network. The M verification nodes in the verification network are composed of first-type business nodes in the business network; M is a positive integer. The method is executed by the first verification node among the M verification nodes, and includes:

[0006] The system obtains a data location request for target business data sent by a business object through a first business node; the first business node belongs to the second type of business node in the business network; the second type of business node is a business node in the business network other than the first type of business node.

[0007] When the target data identifier of the target business data is obtained from the data location request, the first node mapping identifier of the first verification node is determined in the ring mapping space corresponding to the verification network.

[0008] In the addressing direction indicated by the ring mapping space, the target data identifier is checked by the resource location table associated with the first node address of the first node mapping identifier to obtain the first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction;

[0009] When the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the on-chain synchronization data information, the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction will be used as the second node mapping identifier in the node routing list maintained by the first verification node, and the data positioning request carrying the target data identifier will be forwarded to the second verification node corresponding to the second node mapping identifier; when the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, the second verification node is used to verify the authenticity of the target business data.

[0010] This application provides a data processing method based on a hierarchical blockchain network, which includes at least a verification network and a core consensus network. The verification network is deployed in the business network of the hierarchical blockchain network, which is independent of the core consensus network. The M verification nodes in the verification network are composed of first-type business nodes from the business network; M is a positive integer. The method is executed by a second verification node among the M verification nodes, and the method includes:

[0011] The system retrieves a data location request carrying a target data identifier, forwarded by the first verification node among M verification nodes. The data location request is a request sent by a business object through the first business node for the target business data corresponding to the target data identifier. The first business node belongs to the second type of business nodes in the business network. The second type of business nodes are business nodes in the business network other than the first type of business nodes. When the first verification node obtains the target data identifier of the target business data from the data location request, it determines the first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network, and is used to locate the target business data in the addressing direction indicated by the ring mapping space, via the first node mapping identifier. The resource location table associated with the point address performs data verification on the target data identifier to obtain the first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction; the second node mapping identifier of the second verification node refers to the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction in the node routing list maintained by the first verification node when the first data verification result indicates that the synchronization data identifier of the on-chain synchronization data information does not contain the target data identifier;

[0012] When the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, the authenticity of the target business data is verified.

[0013] This application provides a data processing device based on a hierarchical blockchain network. The hierarchical blockchain network includes at least an verification network and a core consensus network. The verification network is deployed within a business network of the hierarchical blockchain network, and the business network is independent of the core consensus network. The M verification nodes in the verification network are composed of first-type business nodes in the business network; M is a positive integer. The device operates in the first verification node among the M verification nodes. The device includes:

[0014] The request acquisition module is used to acquire data location requests for target business data sent by a business object through a first business node; the first business node belongs to the second type of business node in the business network; the second type of business node is a business node in the business network other than the first type of business node.

[0015] The identifier determination module is used to determine the first node mapping identifier of the first inspection node in the ring mapping space corresponding to the inspection network when the target data identifier of the target business data is obtained from the data location request.

[0016] The identifier verification module is used to verify the target data identifier in the addressing direction indicated by the ring mapping space through the resource location table associated with the first node address of the first node mapping identifier, and obtain the first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction;

[0017] The first forwarding module is used to forward the data location request carrying the target data identifier to the second verification node corresponding to the second verification node when the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the on-chain synchronization data information. When the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction in the node routing list maintained by the first verification node, the second verification node is used to verify the authenticity of the target business data.

[0018] The target data identifier is obtained by mapping the target business data to the ring mapping space corresponding to the verification network.

[0019] The identifier determination module includes:

[0020] The address acquisition unit is used to acquire the first node address of the first verification node when the target data identifier of the target business data is obtained from the data location request.

[0021] The address mapping unit is used to map the address of the first node to the ring mapping space to obtain the first node mapping identifier of the first verification node.

[0022] Specifically, the address mapping unit is used to obtain the hash mapping function associated with the ring mapping space, perform a hash operation on the address of the first node based on the hash mapping function, and obtain the first node mapping identifier of the first verification node; the hash mapping function is also used to perform a hash operation on the target business data to obtain the target data identifier of the target business data.

[0023] The identification verification module includes:

[0024] The identifier acquisition unit is used to acquire, in the addressing direction indicated by the ring mapping space, the neighboring node mapping identifier contained in the resource location table associated with the first node address of the first node mapping identifier, and determine the target neighboring node mapping identifier in the neighboring node mapping identifier.

[0025] The identifier verification unit is used to perform data verification on the target data identifier based on the first node mapping identifier and the target neighboring node mapping identifier, and obtain the first data verification result.

[0026] Among them, the synchronization data identifier of the on-chain synchronization data information includes the target synchronization data identifier of the target on-chain synchronization data information stored at the target neighbor node address corresponding to the target neighbor node mapping identifier;

[0027] The identification verification unit includes:

[0028] The first addressing subunit is configured to determine, if the target data identifier is located within the spatial range defined by the first node mapping identifier and the target neighboring node mapping identifier, that the target neighboring node mapping identifier is the node mapping identifier closest to the target data identifier in the addressing direction, and to determine that the target synchronization data identifier contains the target data identifier.

[0029] The second addressing subunit is used to determine that the target data identifier is not included in the target synchronization data identifier if the target data identifier is located outside the spatial range determined by the first node mapping identifier and the target neighboring node mapping identifier.

[0030] The result determination subunit is used to take the data verification result when the target synchronization data identifier contains the target data identifier or when the target synchronization data identifier does not contain the target data identifier as the first data verification result.

[0031] The aforementioned device also includes:

[0032] The second forwarding module is used to forward a data location request carrying the target data identifier to the third verification node corresponding to the target neighbor node mapping identifier when the first data verification result indicates that the target synchronization data identifier contains the target data identifier; the data location request is used to instruct the third verification node to verify the authenticity of the target business data.

[0033] The number of neighboring node mapping identifiers is N; N is a positive integer greater than 1.

[0034] The identifier acquisition unit includes:

[0035] The identifier lookup subunit is used to find the neighboring node mapping identifier corresponding to the first node address located after the first node address in the addressing direction among N neighboring node mapping identifiers, and to use the found neighboring node mapping identifier as the first neighboring node mapping identifier.

[0036] The first identifier determination subunit is used to obtain the node status of the first neighboring verification node corresponding to the first neighboring node mapping identifier. If the node status of the first neighboring verification node is valid, the first neighboring node mapping identifier is used as the target neighboring node mapping identifier.

[0037] The second identifier determination subunit is used to determine the target neighboring node mapping identifier from (N-1) neighboring node mapping identifiers other than the first neighboring node mapping identifier if the node status of the first neighboring inspection node is in an invalid state.

[0038] The aforementioned device also includes:

[0039] The node change module is used to send a node query request to the first neighboring verification node. The node query request is used to instruct the first neighboring verification node to return the predecessor node mapping identifier corresponding to the first node address located in the addressing direction that is preceding the node address corresponding to the first neighboring node mapping identifier. If the predecessor node mapping identifier is different from the first node mapping identifier, the resource location table and the node routing list maintained by the first verification node are updated based on the predecessor node mapping identifier.

[0040] The node routing list contains K routing node mapping identifiers; K is a positive integer greater than 1 and less than or equal to the spatial size parameter of the ring mapping space;

[0041] The first forwarding module includes:

[0042] The identifier lookup unit is used to find the routing node mapping identifier that is the largest distance from the first node mapping identifier among the K routing node mapping identifiers, and to use the found routing node mapping identifier as the first routing node mapping identifier.

[0043] The first identifier determination unit is configured to determine the first routing node mapping identifier as the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction if the first routing node mapping identifier is located within the spatial range determined by the first node mapping identifier and the target data identifier, and to use the first routing node mapping identifier as the second node mapping identifier.

[0044] The second identifier determination unit is used to determine the second node mapping identifier from (K-1) routing node mapping identifiers other than the first routing node mapping identifier if the first routing node mapping identifier is located outside the spatial range determined by the first node mapping identifier and the target data identifier.

[0045] This application provides a data processing device based on a hierarchical blockchain network. The hierarchical blockchain network includes at least an verification network and a core consensus network. The verification network is deployed within a business network of the hierarchical blockchain network, and the business network is independent of the core consensus network. The M verification nodes in the verification network are composed of first-type business nodes from the business network; M is a positive integer. The device operates in a second verification node among the M verification nodes. The device includes:

[0046] The request receiving module is used to acquire a data location request carrying a target data identifier forwarded by the first verification node among M verification nodes. The data location request is a request sent by a service object through the first service node for the target service data corresponding to the target data identifier. The first service node belongs to the second type of service nodes in the service network. The second type of service nodes are service nodes in the service network other than the first type of service nodes. When the first verification node acquires the target data identifier of the target service data from the data location request, it determines the first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network, and is used to locate the target service data in the addressing direction indicated by the ring mapping space by referring to the first node mapping identifier. The resource location table associated with the first node address performs a data verification on the target data identifier to obtain the first data verification result. The neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network. The neighboring node address is the node address located after the first node address in the addressing direction. The second node mapping identifier of the second verification node refers to the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction in the node routing list maintained by the first verification node when the first data verification result indicates that the synchronization data identifier of the on-chain synchronization data information does not contain the target data identifier.

[0047] The authenticity verification module is used to verify the authenticity of the target business data when the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction.

[0048] The target business data is determined by the consensus nodes in the core consensus network after they invoke the target business contract on the blockchain to execute the target transaction; the target business data includes one or more of the target transaction data or target contract data associated with the target transaction; the target transaction is initiated by a second business node; the second business node belongs to the second type of business node in the business network; the above device also includes:

[0049] The data synchronization module is used to obtain the target data identifier and the target verification information of the target business data from the blockchain when the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, and to store the target data identifier and the target verification information.

[0050] The authenticity verification module includes:

[0051] The authenticity verification unit is used to verify the authenticity of the target business data based on the target verification information when the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, and to obtain the second data verification result.

[0052] The proof return unit is used to return the first verification proof information corresponding to the target business data to the business object based on the second data verification result.

[0053] The target verification information includes the Merkel path associated with the target transaction data;

[0054] The authenticity verification unit includes:

[0055] The root verification subunit is used to obtain the transaction hash value of the target transaction data, determine the root to be verified based on the transaction hash value and Merkel path of the target transaction data, obtain the Merkel root in the block header information of the target block where the target transaction data is located, compare the root to be verified with the Merkel root to obtain the root verification result, and determine the second data verification result based on the root verification result.

[0056] The target verification information includes a set of node signatures associated with the target block containing the target transaction data; the set of node signatures includes the node signature information obtained by each of the G consensus nodes in the core consensus network signing the target block; G is a positive integer;

[0057] The authenticity verification unit includes:

[0058] The signature verification subunit is used to obtain the node public keys corresponding to the G consensus nodes, verify the node signature information in the node signature set based on the obtained G node public keys, and obtain the node signature verification result; and determine the second data verification result based on the node signature verification result.

[0059] The target verification information includes first-time association information related to the target transaction data; the first-time association information includes the data timestamp of the target transaction data.

[0060] The authenticity verification unit includes:

[0061] The timestamp verification subunit is used to obtain the timestamp to be verified of the target transaction data from the data location request, compare the timestamp to be verified with the data timestamp to obtain the timestamp verification result, and determine the second data verification result based on the timestamp verification result.

[0062] The target verification information includes second time-related information associated with the target contract data; the second time-related information includes the certificate validity period corresponding to the public key certificate of the consensus node in the core consensus network.

[0063] The authenticity verification unit includes:

[0064] The certificate verification subunit is used to take the public key certificate of the consensus node synchronized from the blockchain as the first public key certificate; the first public key certificate contains the node public key used to verify the node signature set associated with the target block where the target transaction data is located; the usage duration of the first public key certificate is obtained, and the usage duration of the first public key certificate is compared with the certificate validity duration to obtain the certificate validity verification result; the second data verification result is determined based on the certificate validity verification result.

[0065] The second business node stores the original data information of the target business data synchronized from the consensus node; the target verification information includes additional reading information; the additional reading information is determined by the consensus node calling the target business contract to register permissions for the original authorization information submitted by the second business node; the above device also includes:

[0066] The original text verification module is used to obtain the address of the business node that stores the original text information of the target business data when the authenticity verification includes original text verification of the target business data; based on the read additional information, it sends an original text verification request for the target business data to the second business node corresponding to the business node address; the original text verification request is used to instruct the second business node to perform original text verification of the target business data based on the original text information of the target business data, obtain a third data verification result, and return the second verification certificate information corresponding to the target business data to the business object based on the third data verification result.

[0067] The aforementioned device also includes:

[0068] The third forwarding module is used to forward a data location request carrying the target data identifier to the consensus node in the core consensus network when no verification node storing the target verification information is found among the M verification nodes, so that the consensus node can verify the authenticity of the target business data.

[0069] The aforementioned device also includes:

[0070] The fourth forwarding module is used to forward a data location request carrying the target data identifier to the fourth verification node if the node status of the second verification node is invalid or the target verification information stored by the second verification node is missing. The node mapping identifier of the fourth verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, except for the second node mapping identifier. The fourth verification node is used to back up the target verification information. The data location request is used to instruct the fourth verification node to perform authenticity verification on the target business data based on the backed-up target verification information.

[0071] The target business contract is used to determine the verifiable timestamp of the target business data; the aforementioned device also includes:

[0072] The data clearing module is used to obtain the verification time limit event generated by the consensus node based on the verifiable timestamp of the target business data. When the verifiable timestamp in the verification time limit event is obtained, if the data timestamp of the target business data is earlier than the verifiable timestamp, the target data identifier and target verification information are cleared.

[0073] One embodiment of this application provides a computer device, including: a processor and a memory;

[0074] The processor is connected to a memory, which stores a computer program. When the computer program is executed by the processor, it causes the computer device to perform the method provided in the embodiments of this application.

[0075] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0076] One embodiment of this application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in this application embodiment.

[0077] In this embodiment, the first verification node in the verification network can obtain a data location request for target business data sent by a business object through a first business node. Here, the first verification node belongs to a first type of business node in the business network, while the first business node belongs to a second type of business node in the business network. The second type of business node refers to business nodes other than the first type of business nodes in the business network. Further, when the first verification node obtains the target data identifier of the target business data from the data location request, it can determine the first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network. Then, in the addressing direction indicated by the ring mapping space, it can perform data verification on the target data identifier through a resource location table associated with the first node address of the first node mapping identifier to obtain a first data verification result. The neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network. This neighboring node address is the node address located after the first node address in the addressing direction. Furthermore, when the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the on-chain synchronized data information, the first verification node can use the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction from its maintained node routing list as the second node mapping identifier. Then, it can forward the data location request carrying the target data identifier to the second verification node corresponding to the second node mapping identifier. It can be understood that when the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, the second verification node can be used to verify the authenticity of the target business data. As described above, by deploying an verification network in the business network, this application embodiment can support a business object in randomly initiating a data location request for a certain business data (such as the aforementioned target business data) to any verification node (such as the first verification node mentioned above) in the verification network. The verification node can quickly find the verification node (such as the second verification node mentioned above) that is closest to the data identifier of the business data (such as the aforementioned target data identifier) ​​known to the verification node through the resource location table and node routing list maintained by the verification node. The data location request can be forwarded to the second verification node, so that the second verification node can continue to search in a non-linear search method similar to the first verification node until it finds the verification node that is closest to the target data identifier in the addressing direction in the entire verification network. Then, the verification node that is finally found can perform relevant verification on the aforementioned business data. It is understood that, compared with the point-by-point verification method, the non-linear search method adopted in this application embodiment can achieve addressing by jumping to a small number of verification nodes, thereby effectively shortening the addressing distance and thus improving the addressing efficiency of verification nodes, which in turn can improve the verification efficiency of business data. Attached Figure Description

[0078] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0079] Figure 1 This is a schematic diagram of a layered structure of a blockchain network provided in an embodiment of this application;

[0080] Figure 2 This is a schematic diagram of a data processing scenario based on a hierarchical chain network provided in an embodiment of this application;

[0081] Figure 3 This is a flowchart illustrating a data processing method based on a hierarchical chain network provided in an embodiment of this application;

[0082] Figure 4 This is a flowchart illustrating a data processing method based on a hierarchical chain network provided in an embodiment of this application;

[0083] Figure 5 This is a schematic diagram illustrating a scenario for blockchain electronic invoice verification provided in an embodiment of this application;

[0084] Figure 6 This is a schematic diagram illustrating a scenario for blockchain electronic invoice verification provided in an embodiment of this application;

[0085] Figure 7 This is a schematic diagram illustrating a scenario for blockchain electronic invoice verification provided in an embodiment of this application;

[0086] Figure 8 This is a system architecture diagram for a blockchain electronic invoice scenario provided in an embodiment of this application;

[0087] Figure 9 This is a schematic diagram of the structure of a data processing device based on a hierarchical chain network provided in an embodiment of this application;

[0088] Figure 10 This is a schematic diagram of the structure of a data processing device based on a hierarchical chain network provided in an embodiment of this application;

[0089] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0090] Figure 12 This is a schematic diagram of the structure of a data processing system based on a hierarchical chain network provided in an embodiment of this application. Detailed Implementation

[0091] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0092] Please see Figure 1 , Figure 1 This is a schematic diagram of a layered structure of a blockchain network provided in an embodiment of this application. Figure 1 The layered structure of the blockchain network shown can be applied to blockchain systems. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is primarily used to organize data chronologically and encrypt it into a ledger, making it tamper-proof and forgery-proof, while also enabling data verification, storage, and updates. Essentially, a blockchain is a decentralized database where each node stores an identical blockchain record. In this application embodiment, a blockchain network with this layered structure (also known as a two-layer chain structure) can be referred to as a layered chain network. The complete blockchain business system corresponding to this layered chain network can be... Figure 1 It consists of the business network 100a (i.e., the business layer) and the core consensus network 200a (i.e., the core consensus layer).

[0093] It is understandable that in the aforementioned layered blockchain network, the business network 100a (also known as the witness network) and the core consensus network 200a are independent of each other. Network isolation between the business network 100a and the core consensus network 200a can be achieved through a routing network (i.e., a routing proxy layer). For example, the routing nodes in the routing network can be used to layer the peer-to-peer (P2P) network, forming a layered structure of "business network—core consensus network," thereby improving the confidentiality and security of data on the blockchain. The number of routing nodes in the routing network can be one or more, without limitation.

[0094] Understandable Figure 1The business network 100a shown can be deployed with multiple business nodes, and the number of business nodes deployed in business network 100a is not limited here. In this embodiment, business nodes do not need to participate in the accounting consensus; they are mainly used to execute transaction business to obtain transaction data associated with the transaction business and to clear and synchronize the data in a timely manner. Specifically, business nodes can be lightweight nodes that store a portion of the data in the blockchain database. These nodes can complete transaction verification through "Simplified Payment Verification (SPV)," and are therefore also called SPV nodes. For example, in some embodiments, to reduce the waste of storage space for business nodes, business nodes can be lightweight nodes. In this case, business nodes do not need to store complete transaction data, but instead obtain block header data and partially authorized visible block data (e.g., transaction data or contract data associated with the business node itself) from the core consensus network through identity authentication.

[0095] Understandable Figure 1 The core consensus network 200a shown can be deployed with multiple consensus nodes (i.e., ledger nodes), and there is no limit to the number of consensus nodes deployed in the core consensus network 200a. For example, as Figure 1 As shown, the core consensus network 200a can specifically include consensus nodes 130a, 130b, 130c, ..., 130k, which can run blockchain consensus protocols. Specifically, consensus nodes can be full nodes containing a complete blockchain database. These consensus nodes can participate in verifying and broadcasting transaction data and block information, discover and maintain connections with other nodes, and record transaction data and contract data after consensus is achieved into the overall blockchain.

[0096] It should be understood that in this application embodiment, business nodes and consensus nodes located in the above-mentioned layered blockchain network can be collectively referred to as blockchain nodes (or simply nodes). A blockchain node can be a server or a terminal connected to the layered blockchain network. The specific form of the blockchain node is not limited here; each blockchain node can include a hardware layer, a middleware layer, an operating system layer, and an application layer. The server can be a single physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, PDA, mobile internet device (MID), wearable device (e.g., smartwatch, smart bracelet), smart computer, smart vehicle, or other smart terminal.

[0097] Understandable Figure 1 The business network 100a and the core consensus network 200a shown can be in different network environments. For example, in some embodiments, business nodes can be deployed in a public business network, while consensus nodes running the blockchain consensus protocol can be deployed in a private core consensus network. The two can interact through routing boundaries. In this case, since the core consensus network is in a relatively secure private cloud, its mutual access is already secured by a consensus mechanism, and no additional identity management or network control is needed. However, since the business nodes are in a public network, they may be accessed by other uncertain network terminals. Therefore, the access of business nodes and other possible nodes to the core consensus network needs to be strictly controlled. Optionally, in other embodiments, business nodes and consensus nodes can also transmit data directly without going through routing nodes. This application does not limit this.

[0098] It is understandable that the aforementioned layered blockchain network can be applied to various business scenarios such as blockchain electronic invoices and blockchain electronic documents, and no limitation is made here.

[0099] Furthermore, it should be noted that smart contracts can be deployed in a blockchain system. A smart contract in a blockchain system can be understood as code that can be understood and executed by all nodes in the blockchain (e.g., consensus nodes), capable of executing arbitrary logic and obtaining results. In this application embodiment, smart contracts deployed on consensus nodes can be collectively referred to as business contracts. An entity (e.g., a user requesting to execute a transaction) can invoke a contract call request (also known as a transaction request) on its client terminal to call the business contract already deployed on the consensus node. It should be understood that a blockchain system can include one or more smart contracts. These smart contracts (e.g., business contracts) can be distinguished by contract identifiers (e.g., identity document, ID, or name, and may also include contract address or contract function name). The contract call request initiated by the client can also carry the smart contract's identifier or name to specify the smart contract that the blockchain needs to run. If the smart contract specified by the client requires data to be read, the relevant nodes can access local storage to read the data. For transactions that need to be recorded on the blockchain, the consensus nodes will verify each other's execution results (that is, reach a consensus). If they are consistent, the execution results can be stored in their respective local ledgers and returned to the client.

[0100] For ease of understanding and distinction, this application embodiment classifies business nodes in the business network into a first type of business node and a second type of business node. The second type of business node can be understood as a regular business node, primarily responsible for submitting business transactions and synchronizing and clearing business data related to itself. The first type of business node, in addition to performing the functions of a regular business node, can also synchronize data identifiers (e.g., the hash value of the business data) of business data with address spaces similar to its own node, and provide external verification functions for that business data. In this application embodiment, the business data includes transaction data obtained after executing a transaction and contract data associated with that transaction data.

[0101] Based on this, in order to achieve secure and efficient data verification services under the hierarchical structure of "business network - core consensus network", this application embodiment can deploy an verification network in the business network. This verification network can be composed of first-type business nodes in the business network. Simultaneously, a business execution network can also be deployed in the business network, which can be composed of second-type business nodes in the business network. The specific structure of the business network in this application embodiment can be found above. Figure 1 The service network 100a shown can be provided by... Figure 1It consists of a service execution network 110 and a verification network 120, and the service execution network 110 and the verification network 120 are independent of each other.

[0102] Understandable Figure 1 The service execution network 110 shown can be deployed with multiple service nodes; there is no limit to the number of service nodes deployed in the service execution network 110. For example, Figure 1 As shown, the service execution network 110 may specifically include service nodes 110a, 110b, 110c, ..., 110n, all of which belong to the second type of service nodes in service network 100a. The service nodes in service execution network 110 can specifically be SPV nodes, and therefore can also be referred to as service SPV nodes.

[0103] Understandable Figure 1 The verification network 120 shown can be deployed with multiple verification nodes; the number of verification nodes deployed in the verification network 120 will not be limited here. For example, as Figure 1 As shown, the verification network 120 may specifically include verification nodes 120a, 120b, 120c, ..., 120m, all of which belong to the first type of service nodes in the service network 100a. The verification nodes in the verification network 120 can specifically be SPV nodes, and therefore can also be referred to as verification SPV nodes. It can be understood that the verification network in this embodiment can be a network operating based on a specific addressing algorithm (such as the Chord algorithm), which can be used to achieve addressing between multiple verification nodes, and perform relevant verification after successful addressing.

[0104] It should be noted that the second type of business nodes in the business execution network and the first type of business nodes in the verification network are essentially both business nodes deployed in the business network. However, for ease of explanation, the first type of business nodes in the verification network will be referred to as verification nodes, while the second type of business nodes in the business network other than verification nodes will still be referred to as business nodes. It can be understood that business nodes in the business execution network and verification nodes in the verification network can access each other. For example, a business node in the business execution network can send a request to any verification node to verify certain business data; or, for example, if it is necessary to verify the specific original data information of a certain business data, the corresponding verification node can access the business node in the business execution network where that original data information is located.

[0105] Understandably, whether a business node in the business network belongs to the first or second category is not fixed but constantly changing. For example, since verification nodes in the verification network need to be online stably for a long time and can be run by official or authoritative alliance members, any business node in the business network can join the verification network as a first-category business node after meeting the specified verification network joining conditions. Otherwise, the business node will be a second-category business node, only performing ordinary SPV functions and not joining the verification network. Thus, if a business node joins the verification network for a period of time and then goes offline for some reason, and fails to meet the verification network joining conditions after coming back online, the business node can join the business execution network as a second-category business node. If it subsequently meets the verification network joining conditions, it can have the opportunity to rejoin the verification network. The conditions for joining the verification network may specifically include meeting conditions such as being continuously online for a certain period of time (i.e., the continuous online time of the business node is greater than the online time threshold, for example, 5 days) and having a ping return latency lower than the latency threshold (for example, 10ms) before joining the verification network. This application embodiment does not limit these conditions.

[0106] This application provides a business data verification method based on Chord addressing. The core of this method is the design of an independent verification network outside of business SPV nodes (i.e., second-type business nodes) within a hierarchical structure of "business network—core consensus network." This network supports targeted data addressing and verification among multiple verification SPV nodes. The addressing algorithm can utilize the Chord algorithm, thereby providing high efficiency and overall security for business data addressing and verification. For ease of understanding and explanation, this application can refer to any entity object (e.g., individual user, enterprise user, organization, etc.) with business data verification needs as a business object. Furthermore, this application can refer to any business node in the business execution network that interacts with the business object as a first business node (e.g., business node 110a). When a business object wishes to verify the authenticity of certain business data (i.e., target business data) on the chain, the first business node can delegate any verification node in the verification network (e.g., verification node 120a) to provide proof of authenticity to the business object. Here, the first business node belongs to the second-type business node in the business network. In this embodiment, the target business data may include one or more of the target transaction data or target contract data obtained after executing the target transaction business, without limitation. The target transaction business here can be a transaction initiated by an entity (which may be called the business initiating object, and may be the same as or different from the aforementioned business object) through a second business node. This second business node (e.g., business node 110b) belongs to the second type of business node in the business network, meaning the second type of business node is any business node in the business execution network. It should be noted that the second business node and the first business node can be the same business node or different business nodes, without limitation. Similarly, it can be understood that, assuming the number of verification nodes in the verification network is M (M is a positive integer), these M verification nodes are composed of the first type of business nodes in the business network. In this embodiment, the verification node entrusted by the business object to verify the target business data among these M verification nodes can be called the first verification node. This first verification node can be any verification node among the M verification nodes (e.g., verification node 120a). It is understandable that if no relevant data is found at the first verification node, the query can be skipped to the next verification node. Similarly, the verification node can be called the second verification node, and so on.

[0107] The transaction business may include, but is not limited to, bill business (such as electronic bill issuance, electronic bill circulation, electronic bill red-inking, electronic bill archiving, and other businesses related to electronic bills), bill-related derivative businesses (such as credit business, import and export loss business, enterprise qualification business, credit investigation business, social business, credit purchase business and tax refund business, lottery business, etc.), document business (such as electronic document issuance, electronic document circulation, electronic document correction, electronic document archiving, and other businesses related to electronic documents), and document-related derivative businesses (such as institutional cooperation business, enterprise qualification business, prescription statistics business, qualification review business, and government administration business). The aforementioned target transaction business can be any transaction business requested by the business initiator (such as electronic invoice issuance business); correspondingly, the transaction data generated after executing these transaction businesses (such as the aforementioned target transaction data) may include, but is not limited to, electronic invoices associated with the invoice business, partially authorized visible invoice information in the electronic invoice (e.g., invoice number, header, etc.), general invoice-related assets associated with the electronic invoice (e.g., credit information, tax information, etc.), and electronic documents associated with the document business or partially authorized visible document information in the electronic document (e.g., certificate information in an electronic certificate), and general document-related assets associated with the electronic document (e.g., qualification information, prescription statistics, etc.). In addition, contract data associated with the transaction data (such as the aforementioned target contract data) may include the data state of the business initiator after calling the business contract on the blockchain to execute the transaction business (such as the transaction read / write set obtained after executing the transaction business).

[0108] Accordingly, the business contracts used to execute the above-mentioned transactions may include, but are not limited to, electronic invoice issuance contracts, electronic invoice circulation contracts, electronic invoice red-inking contracts, electronic invoice archiving contracts, invoice derivative business contracts, tax application contracts, electronic document issuance contracts, electronic document circulation contracts, electronic document correction contracts, electronic document archiving contracts, and document derivative business contracts, etc., without limitation here.

[0109] It is understood that, in this application embodiment, a blockchain node can be configured for any role (e.g., any individual user, any enterprise, any organization, or other entity) accessing the layered blockchain network through consensus nodes in the core consensus network (such as the core consensus network 200a described above). Therefore, in such cases... Figure 1In the business execution network 110 shown, business nodes 110a, 110b, 110c, 110d, ..., 110n can each have a one-to-one correspondence with the corresponding roles (such as the aforementioned business initiator or business object) that need to access this hierarchical blockchain network. Taking a business initiator requesting the execution of a certain transaction as an example, in this case, the blockchain node associated with each enterprise user can be the same blockchain node (e.g., the aforementioned...). Figure 1 The business node 110c shown can interact with the business terminals corresponding to multiple enterprise users. For example, in a blockchain electronic invoice scenario, the invoice services requested by each enterprise user (such as electronic invoice issuance, electronic invoice circulation, electronic invoice red-inking, electronic invoice archiving, and other electronic invoice-related services) can be collectively referred to as a single transaction. Specifically, when the aforementioned enterprise user is enterprise A requesting invoice issuance through the core consensus network 200a, it can... Figure 1 The business node 110c shown interacts with the consensus nodes (e.g., consensus node 130a) in the core consensus network 200a to request the completion of the corresponding transaction; similarly, the invoicing company B can also... Figure 1 The business node 110c shown interacts with the consensus nodes (e.g., consensus node 130a) in the core consensus network 200a to request the completion of the corresponding transaction; similarly, the invoicing company C can also... Figure 1 The business node 110c shown interacts with the consensus nodes (e.g., consensus node 130a) in the core consensus network 200a to request the completion of the corresponding transaction.

[0110] For ease of understanding, this application embodiment can take a bill business (e.g., electronic bill issuance business) as an example. When a business node associated with a business initiator (e.g., invoicing company A) receives a transaction business request related to the transaction business, it can forward the transaction business request initiated by the business initiator to a consensus node in the core consensus network. The consensus node can then verify the legality of the transaction business request initiated by the business initiator. In this way, when the transaction legality verification is successful, the consensus node can add the transaction business requested by the business initiator (e.g., the aforementioned bill business) to the transaction pool. This allows the transaction data associated with the transaction business (e.g., the aforementioned bill business) to be packaged into blocks for block consensus among consensus nodes in the core consensus network. After block consensus is successful, the block data can be written to the local cache and local storage, enabling parallel storage of block data for multiple blocks based on the aforementioned distributed storage.

[0111] Furthermore, it is understandable that the Chord algorithm is a consistent hashing algorithm, primarily used to solve the address management and addressing calculation of a large number of nodes in a network. Each node can map its own address to a global address space and, through corresponding routing table designs, record nodes in this global address space that are at different distances from itself. This allows the entire network to have the ability to discover and address nodes. In the embodiments of this application, the Chord algorithm can be used as a P2P protocol to solve the data location problem within a business network, enabling the traversal of multiple nodes to find the data resources sought by the business object.

[0112] Based on this, in this embodiment of the application, the first verification node in the verification network (such as the aforementioned verification node 120a) can obtain a data location request for target business data sent by the business object through the first business node (such as the aforementioned business node 110a). Further, when the first verification node obtains the target data identifier of the target business data from the data location request, it can determine the first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network. Then, in the addressing direction indicated by the ring mapping space, it can perform data verification on the target data identifier through a resource location table associated with the first node address of the first node mapping identifier to obtain the first data verification result. The neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network. This neighboring node address is the node address located after the first node address in the addressing direction. Furthermore, when the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the on-chain synchronization data information, the first verification node can use the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction in its maintained node routing list as the second node mapping identifier. Then, it can forward the data location request carrying the target data identifier to the second verification node corresponding to the second node mapping identifier (e.g., verification node 120d). It can be understood that when the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, the second verification node can be used to verify the authenticity of the target business data.

[0113] As described above, by deploying an verification network in the business network, this application embodiment can support a business object in randomly initiating a data location request for a certain business data (such as the aforementioned target business data) to any verification node (such as the first verification node mentioned above) in the verification network. The verification node can quickly find the verification node (such as the second verification node mentioned above) that is closest to the data identifier of the business data (such as the aforementioned target data identifier) ​​known to the verification node through the resource location table and node routing list maintained by the verification node. The data location request can be forwarded to the second verification node, so that the second verification node can continue to search in a non-linear search method similar to the first verification node until it finds the verification node that is closest to the target data identifier in the addressing direction in the entire verification network. Then, the verification node that is finally found can perform relevant verification on the aforementioned business data. Compared to point-by-point verification, the non-linear search method employed in this application embodiment can achieve addressing by jumping to a small number of verification nodes, thereby effectively shortening the addressing distance and improving the addressing efficiency of verification nodes, which in turn improves the verification efficiency of business data. Furthermore, since the verification network and the second type of business nodes storing business data are separated, the privacy of the business data is guaranteed, thus maintaining the overall security of the business network during the data verification process.

[0114] For better understanding, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram of a data processing scenario based on a hierarchical chain network provided in an embodiment of this application. For example... Figure 2 The inspection node 20A shown can serve as the first inspection node mentioned above. Figure 1 Any one of the verification nodes in the verification network 120 shown (e.g., verification node 120a). Figure 2 The inspection node 20B shown can serve as the aforementioned second inspection node, and this inspection node 20B can serve as the aforementioned Figure 1 Any one of the verification nodes in the verification network 120 shown (e.g., verification node 120c). Furthermore, as... Figure 2 User X can be considered the aforementioned business object, and the business node 20C associated with user X can be considered the aforementioned first business node. This business node 20C can be the aforementioned... Figure 1Any one of the service nodes (e.g., service node 110a) in the service execution network 110 shown. It can be understood that service node 20C can be the service node determined when the service terminal used by user X accesses the service network as a service node, or service node 20C can be the service node corresponding to the service terminal used by user X; this is not limited here. It can be understood that verification node 20A, verification node 20B, and service node 20C are all deployed in the same service network (as described above). Figure 1 In the business network 100a) shown, verification nodes 20A and 20B belong to the first type of business nodes in the business network, and business node 20C belongs to the second type of business nodes in the business network.

[0115] It is understandable that when user X obtains certain business data (i.e., target business data, for example, business data 201a) and wishes to verify the authenticity of business data 201a on the blockchain, the first step is to perform addressing within the business network to locate a verification node capable of verifying the authenticity of business data 201a. If the verification requires access to the original text, the verification node can further access the specific business node where business data 201a resides (this business node synchronously holds the original text of business data 201a). Business data 201a may contain only relevant transaction data, only relevant contract data, or both transaction data and contract data; this is not limited here. In this embodiment, for ease of distinction, the transaction data in the target business data can be referred to as target transaction data; similarly, the contract data in the target business data can be referred to as target contract data. For example, suppose business data 201a is business data associated with a certain transaction business (such as asset transfer business). In the asset transfer scenario, the transaction data in business data 201a may include transaction data A1 generated when user 1 transfers virtual assets (such as electronic tickets, game coins, game diamonds, etc.) to user 2. The contract data A2 related to the transaction data A1 may be the remaining asset amount of user 1 and user 2 after user 1 transfers a certain amount of virtual assets to user 2.

[0116] It is understandable that, in order to achieve efficient addressing, the addressing algorithm used in the network can be the Chord algorithm or other available addressing algorithms. This application uses the Chord algorithm as an example for illustration. The Chord algorithm is often used to construct distributed hash tables (DHTs) for structured P2P networks. The main idea of ​​DHT is to make the access to resources on the network as simple and fast as reading and writing in a hash table. First, each file index is represented as a (K, V) pair, where K is called the key, which can be the hash value of the filename (or other descriptive information of the file), and V is the IP (Internet Protocol) address (or other descriptive information of the node that actually stores the file). All file index entries (i.e., all (K, V) pairs) form a large file index hash table. As long as the K value of the target file is input, the addresses of all nodes storing that file can be found from this table. Then, the large file index hash table is divided into many smaller local blocks. These local hash tables are distributed across all participating nodes in the system according to specific rules, with each node responsible for maintaining one block. Thus, when a node queries a file, it only needs to route the query message to the appropriate node (whose hash table block contains the (K, V) pair to be searched). Borrowing from this idea, the Chord algorithm ensures consistent hashing by mapping node addresses (i.e., Nodes, which may include the node's IP address and port number) and resources (i.e., Keys) to the same space. To ensure the non-repetitiveness of the hash, the Chord algorithm can choose a specified hash function (such as SHA-1, i.e., Secure Hash Algorithm 1), which produces a 2^32 hash. m The hash space has values ​​ranging from 0 to 2. m -1, each hash value is an m-bit integer. These hash values ​​are linked together to form a virtual ring called the Chord Ring. The hash values ​​are arranged clockwise on the Chord Ring. Node addresses and resources are mapped to the Chord Ring, thus assuming the entire P2P network is a virtual ring. In a clockwise direction, the node preceding node x is called its predecessor (or successor), and the first predecessor is called its direct predecessor. Similarly, the node following node x is called its successor, and the first successor is called its direct successor.

[0117] Based on this, when the Chord algorithm is used in the verification network, a circular hash space (i.e., a Chord ring) is also obtained. In this embodiment, this hash space can be referred to as a ring mapping space. This ring mapping space can be organized according to a specified addressing direction. Correspondingly, when addressing in this ring mapping space, the addressing direction can be clockwise along the ring mapping space. Furthermore, this ring mapping space is a consistent hash ring with a size of 2. m m is a positive integer, and its value ranges from 0 to 2. m -1, Figure 2 A ring mapping space with m=6 is shown. This application does not limit the value of m; for example, in some embodiments, m=256. In this way, the node address of each authenticating node in the verification network can be mapped to this ring mapping space, thereby obtaining a node mapping identifier (i.e., NodeID) corresponding to a certain position in the ring mapping space. Figure 2 (As shown); similarly, the business data stored in the business nodes can also be mapped to this ring mapping space, thereby obtaining a data identifier (i.e., KeyID) corresponding to a certain position in the ring mapping space. The length of both the node mapping identifier and the data identifier is m. That is, the node mapping identifier and the data identifier are assigned to a space of size 2. m On the ring, resources are allocated (to a specific node) and distributed across nodes, as well as located. For ease of understanding and distinction, in this embodiment, the node address of the first verification node can be referred to as the first node address, and the node mapping identifier obtained by mapping the first node address to the ring mapping space can be referred to as the first node mapping identifier; similarly, the node address of the second verification node can be referred to as the second node address, and the node mapping identifier obtained by mapping the second node address to the ring mapping space can be referred to as the second node mapping identifier, and so on. Similarly, the data identifier obtained by mapping the target business data to the ring mapping space can be referred to as the target data identifier. The following will combine... Figure 2 This section describes the specific process of addressing in a network verification system.

[0118] It is understood that in this embodiment of the application, the verification network contains M verification nodes (M is a positive integer), for example, such as Figure 2 As shown, assuming M = 10, that is, the verification network contains 10 verification nodes (including verification node 20A and verification node 20B), and the ring mapping space corresponding to the verification network is a space of size 2. 6 The ring (i.e., m = 6) has a value range of 0 to 2. 6-1 indicates that after mapping the node addresses of the 10 verification nodes to the ring mapping space, the node mapping identifiers of each verification node can be obtained, each of which is a 6-bit integer. These 10 node mapping identifiers are placed in the ring mapping space in ascending order according to the specified addressing direction (e.g., clockwise). For example, the 10 node mapping identifiers in clockwise order are identifier N1, identifier N8, identifier N14, identifier N21, identifier N32, identifier N38, identifier N42, identifier N48, identifier N51, and identifier N56. Similarly, assuming there are currently 5 business data items (including business data 201a), after mapping these 5 business data items to the ring mapping space, the data identifiers of each business data item can be obtained, each of which is a 6-bit integer. Subsequently, the obtained data identifiers can be assigned to the verification node corresponding to the nearest node mapping identifier in the addressing direction (e.g., clockwise) indicated by the ring mapping space. In other words, any verification node can synchronize data identifiers that are close to its own node mapping identifier. Specifically, a data identifier KeyID can be assigned to the verification node corresponding to the first NodeID (NodeID >= KeyID). This verification node can then be called the successor node of the business data corresponding to the data identifier KeyID; that is, this verification node is the first verification node on the ring in the addressing direction starting from KeyID, and can be denoted as successor(KeyID). For example, assuming the data identifiers of the above 5 business data are identifiers K10, K24, K30, K38, and K54, resource allocation can be performed based on these data identifiers, for example... Figure 2 As shown, the successor node of the business data corresponding to identifier K10 is the verification node corresponding to identifier N14. That is to say, identifier K10 is assigned to the verification node corresponding to identifier N14, and the subsequent verification node corresponding to identifier N14 will be responsible for addressing the business data corresponding to identifier K10.

[0119] Based on this, such as Figure 2 As shown, user X can send a data location request (e.g., data location request 201b) for business data 201a to verification node 20A in the verification network through the associated service node 20C. After receiving the data location request 201b, verification node 20A can obtain the data identifier of business data 201a (i.e., the aforementioned target data identifier, e.g., data identifier 201c) from the data location request 201b. This data identifier 201c maps business data 201a to a specific target data identifier, such as... Figure 2 The ring mapping space shown is obtained; in addition, the node address of the verification node 20A (i.e., the aforementioned first node address) can also be mapped to, as shown in the figure. Figure 2In the ring mapping space shown, the node mapping identifier of the verification node 20A (i.e., the aforementioned first node mapping identifier, for example, node mapping identifier 201d) is obtained; simultaneously, the node address of the verification node 20B (i.e., the aforementioned second node address) can be mapped to, as shown in the figure. Figure 2 In the ring mapping space shown, the node mapping identifier of the verification node 20B (i.e. the aforementioned second node mapping identifier, for example, node mapping identifier 201h) is obtained.

[0120] Furthermore, the verification node 20A can obtain a resource location table (e.g., resource location table 201e) associated with the node address corresponding to its node mapping identifier 201d. This resource location table can be used to record neighboring node mapping identifiers, and the node address of the verification node corresponding to the neighboring node mapping identifier can be called the neighboring node address. This neighboring node address is the node address located after the node address of verification node 20A in the addressing direction. That is, the verification node corresponding to the neighboring node mapping identifier is the successor node of verification node 20A. This application embodiment does not limit the specific number of neighboring node mapping identifiers stored in the resource location table. It can be understood that the neighboring node address can also be used to store the data identifiers allocated to itself, and these data identifiers are also data identifiers of related business data. For ease of distinction, these data identifiers can be collectively referred to as synchronization data identifiers, and the business data corresponding to the synchronization data identifiers can be collectively referred to as on-chain synchronization data information. Here, the synchronization data identifiers are synchronized from the blockchain corresponding to the core consensus network by the verification node corresponding to the neighboring node mapping identifier, while the on-chain synchronization data information can be synchronized and cleared by the relevant business nodes.

[0121] For example, such as Figure 2 As shown, assuming that the node mapping identifier 201d of the verification node 20A is specifically the aforementioned identifier N8, and the resource location table 201e associated with the node address of this identifier N8 contains four neighboring node mapping identifiers, namely identifiers N14, N21, N32 and N38, it can be understood that the verification nodes corresponding to these four neighboring node mapping identifiers are all successor nodes of the verification node 20A. In addition, the neighboring node address corresponding to each neighboring node mapping identifier (i.e., the node address of these successor nodes) can be used to store the synchronization data identifier of the on-chain synchronization data information related to itself. For example, taking the neighboring node mapping identifier as identifier N14 as an example, the verification node corresponding to identifier N14 can synchronize five synchronization data identifiers of on-chain synchronization data information, namely the identifier E1 of on-chain synchronization data information 1, the identifier E2 of on-chain synchronization data information 2, the identifier E3 of on-chain synchronization data information 3, the identifier E4 of on-chain synchronization data information 4 and the identifier E5 of on-chain synchronization data information 5.

[0122] Furthermore, when the node mapping identifier 201d of the verification node 20A is the aforementioned identifier N8, the verification node 20A can perform data verification on the data identifier 201c of the business data 201a through the resource location table 201e in the addressing direction indicated by the ring mapping space (such as clockwise direction), thereby obtaining the corresponding data verification result (i.e., the first data verification result, such as data verification result 201f). The purpose of this data verification is to determine whether the successor node of the verification node 20A holds the currently searched data identifier 201c. For example, assuming the data identifier 201c of business data 201a is the aforementioned identifier K24, the verification node 20A with identifier N8 can first look up the node mapping identifier of its direct successor node in the resource location table 201e, i.e., identifier N14. At this point, it can be found that the required identifier K24 does not fall between identifier N8 and identifier N14 (i.e., identifier K24 is outside the spatial range [N8, N14]). Therefore, it can be determined that identifier K24 does not exist on the verification node corresponding to identifier N14. The five synchronized data identifiers (identifiers E1 to E5) synchronized by the verification node do not include identifier K24. It is understandable that when the direct successor node of verification node 20A fails, data verification related to that direct successor node cannot be performed. In this case, data verification can be performed sequentially through resource location table 201e. For example, when the verification node corresponding to identifier N14 is detected to be failed, verification node 20A can determine, through a similar process, whether the next successor node (i.e., the verification node corresponding to identifier N21) holds identifier K24.

[0123] Optionally, when the data verification result 201f indicates that the synchronization data identifier stored in the direct successor node of the verification node 20A (such as the verification node corresponding to the identifier N14 mentioned above) contains the data identifier 201c, the addressing ends, and the verification node 20A can directly forward the data location request 201b to the direct successor node to verify the authenticity of the business data 201a.

[0124] Optionally, if data verification result 201f indicates that data identifier 201c is not included in the synchronization data identifiers stored in the direct successor node of verification node 20A (such as the verification node corresponding to identifier N14 mentioned above), verification node 20A can continue addressing through its maintained node routing list (Finger Table). For example, as Figure 2As shown, when the node mapping identifier 201d of the query node 20A is the aforementioned identifier N8, the node routing list maintained by the query node 20A is the node routing list 201g. This node routing list is used to store the routing information (i.e., routing entries) corresponding to positions at a distance of 2^(1,2,3,…) from the query node 20A, starting from the addressing direction indicated by the current query node 20A to the ring mapping space. This node routing list can store at most m routing entries, therefore the complexity of this routing algorithm is O(log N). Assuming the value of the node mapping identifier 201d is n, then the i-th routing entry in its node routing list stores the (n+2)-th routing entry of the query node 20A. i-1 )mod 2 m The node mapping identifier of each successor node is defined as follows: the distance between the node mapping identifier of the successor node stored in the node routing list and the node mapping identifier of the queuing node 20A increases proportionally to a multiple of 2. The modulo operation is used because the successor of the final queuing node is one of the first few queuing nodes. For example, in the ring mapping space, the next queuing node in the addressing direction of the queuing node with the largest node mapping identifier (e.g., the queuing node corresponding to identifier N56) is defined as the first queuing node. Where 1 <= i <= m.

[0125] For example, such as Figure 2 As shown in node route list 201g, node route list 201g stores 6 routing information items. The left column records N8+1 (i.e., 2) on the ring mapping space. 1-1 ) to N8+32 (i.e. 2 6-1 The right column records the node mapping identifier of the actual tracing node corresponding to each location. In this embodiment, for ease of distinction, the node mapping identifier stored in the node routing list can be called the routing node mapping identifier. For example, the first routing information in the node routing list 201g is N8+1—N14, which means that the resource (such as the data identifier) ​​located at the first position after the tracing node corresponding to the identifier N8 in the addressing direction will be the responsibility of the tracing node corresponding to the identifier N14. This recording has the following advantages: (1) Each tracing node only contains information on a small portion of the tracing nodes in the entire network; (2) Each tracing node knows more about the positions of the tracing nodes that are close to each other. For example, the tracing node corresponding to the identifier N8 knows three positions (i.e., N8+1, N8+2, and N8+4) of the positions of the tracing node corresponding to the identifier N14, but only knows one position (i.e., N8+8) of the positions of the tracing node corresponding to the identifier N21.

[0126] Based on this, when the verification node 20A searches for an address in the node routing list 201g, it can first find the node mapping identifier (e.g., node mapping identifier 201h) that is closest to the data identifier 201c in the reverse direction of the addressing direction (e.g., counterclockwise) as the second node mapping identifier. It can be understood that the found node mapping identifier 201h is smaller than the data identifier 201c. Then, it can jump to the verification node (i.e., the second verification node) corresponding to the node mapping identifier 201h to continue the search. For ease of understanding, this example will still use node mapping identifier 201d as identifier N8 and data identifier 201c as identifier K24. Figure 2 As shown, among the six route node mapping identifiers (i.e., identifiers N14, N14, N14, N21, N32, and N42) contained in the node routing list 201g, the route node mapping identifier closest to identifier K24 in the counterclockwise direction is identifier N21. It can be understood that at this time, identifier N21 < identifier K24, that is, N8+8—N21 satisfies the condition that identifier N21 is within the spatial range (N8, K24]. Therefore, the aforementioned node mapping identifier 201h is identifier N21. Assuming... Figure 2 The node mapping identifier of verification node 20B shown is also identifier N21. Therefore, verification node 20B can act as a second verification node. Subsequently, verification node 20A can forward the data location request 201b carrying data identifier 201c (i.e., identifier K24) to verification node 20B. It can be understood that after receiving the data location request 201b, verification node 20B will also perform an addressing process similar to that of verification node 20A until it finds the node mapping identifier closest to data identifier 201c in the addressing direction. The addressing ends when the node is finally found. The verification node finally found is then used to further verify the authenticity of business data 201a. For example, as... Figure 2 As shown, similarly, the verification node 20B corresponding to identifier N21 can first determine whether its direct successor node (i.e., the verification node corresponding to identifier N32) holds the currently searched identifier K24. At this time, if the verification node 20B finds that identifier K24 falls between identifier N21 and identifier N32 (i.e., identifier K24 is located within the spatial range (N21, N32)), it can determine that identifier N32 is the node mapping identifier closest to identifier K24 in the addressing direction. In other words, the currently searched identifier K24 exists on the verification node corresponding to identifier N32. Therefore, the verification node corresponding to identifier N32 can verify the authenticity of the business data (i.e., business data 201a) corresponding to identifier K24.

[0127] Alternatively, when the node mapping identifier 201h of the verification node 20B is the node mapping identifier closest to the data identifier 201c in the addressing direction, the verification node 20B can verify the authenticity of the business data 201a and return a verification certificate for the business data 201a to user X. Furthermore, when original text verification is involved, the verification node 20B can also access the specific business node where the business data 201a resides.

[0128] As described above, in a layered blockchain network, this application provides a business data verification framework and protocol based on the Chord algorithm. This framework enables efficient data verification between multiple verification nodes through routing, thereby improving the efficiency of business data verification by enhancing the addressing efficiency of the verification nodes. Furthermore, this application designs a data verification scheme for a two-layer blockchain system, featuring an independent verification network. This verification network is stable, distributed, and highly fault-tolerant, and can be separated from the business SPV nodes. While ensuring business data privacy, it provides stable blockchain data verification services. Simultaneously, the verification network isolates the core consensus network, preventing query requests from repeatedly entering the core consensus network and impacting its performance. This also allows for full utilization of the computing resources of the business network.

[0129] It should be understood that the methods provided in this application embodiment can be applied to business scenarios such as transferring virtual assets (e.g., electronic invoices, game coins, game diamonds, etc.), transferring electronic documents (e.g., electronic contracts, electronic official documents, etc.), or other business scenarios that require business data verification.

[0130] Furthermore, it is understood that the specific implementation of this application may involve business data of entities such as users, enterprises, and institutions (e.g., users' invoicing information, credit information, tax refund information, etc.; enterprises' income and loss, enterprise qualifications, etc.; users' or enterprises' contract information, certificate information, prescription information, etc.). When the above embodiments of this application are applied to specific products or technologies, permission or consent from users, enterprises, institutions, and other business entities is required, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0131] In the hierarchical structure of "business network - core consensus network", the first verification node obtains the target data identifier from the data location request for the target business data, determines the first node mapping identifier of the first verification node in the ring mapping space, and performs data verification on the target data identifier in the addressing direction indicated by the ring mapping space by comparing it with the corresponding resource location table. If the target data identifier is not included in the synchronization data identifier, it searches for the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction through its maintained node routing list as the second node mapping identifier, and then forwards the data location request to the second verification node corresponding to the second node mapping identifier. The specific implementation of the second verification node verifying the authenticity of the target business data when the second node mapping identifier is the node mapping identifier closest to the target data identifier in the addressing direction can be found in the following. Figures 3-8 The corresponding implementation examples.

[0132] For further details, please see Figure 3 , Figure 3 This is a flowchart illustrating a data processing method based on a hierarchical chain network provided in an embodiment of this application. Figure 3 As shown, the hierarchical blockchain network includes at least an verification network and a core consensus network. The verification network is deployed within the business network of the hierarchical blockchain network, and the business network is independent of the core consensus network. The M verification nodes in the verification network are composed of the first type of business nodes in the business network. The method can be executed by the first verification node among the M verification nodes; for example, the first verification node can be the aforementioned... Figure 1 Any one of the verification nodes (such as verification node 120a) in the verification network 120 shown. Specifically, this method may include the following steps S101-S104:

[0133] Step S101: Obtain the data location request for the target business data sent by the business object through the first business node;

[0134] It is understandable that when a business object obtains target business data, if it wants to verify the authenticity of the target business data on the blockchain, it can entrust any verification node in the verification network to provide it with proof of authenticity. Therefore, the business object can send a data location request for the target business data to the first verification node in the verification network through the first business node in the business network, and the first verification node can receive the data location request. Here, the first business node belongs to the second type of business node in the business network, and the second type of business node refers to business nodes in the business network other than the first type of business nodes. For example, the first business node can be one of the aforementioned... Figure 1 Any one of the service nodes (such as service node 110a) in the service execution network 110 shown.

[0135] It is understandable that each business node only synchronizes transaction data and contract data related to itself, so the business data stored by different business nodes may be different; similarly, each verification node only synchronizes data identifiers (such as hash values) of transaction data and contract data that are close to its own node's address space. Therefore, when requesting to verify certain business data, it is necessary to perform the corresponding addressing process to find the verification node that can verify the authenticity of the business data and the business node that can verify the original text of the business data.

[0136] It is understood that the target business data in this embodiment is determined by the consensus node in the core consensus network calling the target business contract on the blockchain to execute the target transaction. Specifically, when the second business node in the business network obtains the target transaction requested by the business initiator, it can execute the target transaction to obtain the corresponding transaction data. For example, in the scenario of electronic invoice issuance, assuming a patient goes to a hospital in region A for treatment, the business node in region A can issue an electronic invoice for the virtual assets spent on this treatment, and then generate corresponding transaction data based on the electronic invoice. Here, the second business node belongs to the second type of business node in the business network. For example, the second business node can be the aforementioned Figure 1The second business node (e.g., business node 110b) can be any business node in the business execution network 110 shown. This second business node can be the same as or different from the first business node mentioned above; this is not a limitation. Further, the second business node can send the target transaction business and the obtained transaction data to the consensus node in the core consensus network. When the consensus node obtains a transaction list containing the target transaction business from the relevant transaction pool, it can call the target business contract deployed on the blockchain to execute the target transaction business. For example, based on the target business contract, it can read the read dataset corresponding to the target transaction business, and then execute the target transaction business based on the read dataset to obtain the transaction execution result corresponding to the target transaction business. Then, based on the transaction execution result, it can obtain the corresponding target transaction data (e.g., transaction data B1), and write the transaction execution result to the write dataset corresponding to the target transaction business. At this time, the transaction read and write sets (including read datasets and write datasets) obtained after executing the target transaction business can be used as the corresponding target contract data (e.g., contract data B2). Furthermore, consensus nodes can package the aforementioned transaction list and all or part of the data related to that transaction list (e.g., transaction data, transaction execution results, read datasets, write datasets, etc.) into a target block. After the target block passes consensus, it can be written to the blockchain corresponding to the core consensus network. This application embodiment does not limit the data content packaged into the block. It is understood that consensus nodes can store the final target block in their own node memory.

[0137] The target transaction business mentioned above can be any type of transaction business, such as the bill business, bill derivative business related to the bill business, document business, and document derivative business related to the document business, etc.

[0138] It is understood that, in the embodiments of this application, one or more of the above-mentioned target transaction data or target contract data can be used as target business data. After the target business data is successfully uploaded to the chain, the second business node can synchronize and clear the target business data, and can also send the synchronized target business data to the aforementioned business object.

[0139] Step S102: When the target data identifier of the target business data is obtained from the data location request, the first node mapping identifier of the first inspection node is determined in the ring mapping space corresponding to the inspection network.

[0140] It is understandable that, in order to achieve efficient data verification, this application embodiment may employ the Chord algorithm to map the node address of the verification node and the business data stored in the business node to the ring mapping space corresponding to the verification network, thereby ensuring consistent hashing. The distribution of the obtained node mapping identifier and data identifier in the ring mapping space can be seen above. Figure 2 The corresponding embodiment. The size of the ring mapping space is 2. m m is a positive integer, and the range of values ​​in the ring mapping space is 0 to 2. m -1.

[0141] In this context, the target data identifier is obtained by mapping the target business data to the ring mapping space corresponding to the verification network. Specifically, when a consensus node obtains the target business data, it can acquire the hash mapping function associated with the ring mapping space. Then, it can perform a hash operation on the target business data based on this hash mapping function to obtain the corresponding target data identifier. In this embodiment, the hash mapping function can be a constant hash function such as SHA-1 or SHA256. That is, for input data of any length, its output is a hash value of fixed length. For example, SHA256 will produce a 256-bit hash value. Correspondingly, when using SHA256 as the hash mapping function, m = 256, meaning the size of the corresponding ring mapping space is 2^356. 256 In practical applications, a suitable hash mapping function can be selected according to business needs. The obtained target data identifier can be the hash value of some or all of the data in the target business data. For example, optionally, when the target business data only contains target transaction data, the corresponding target data identifier can be the hash value of some or all of the data in that target transaction data; optionally, when the target business data only contains target contract data, the corresponding target data identifier can be the hash value of some or all of the data in that target contract data; optionally, when the target business data contains both target transaction data and target contract data, the corresponding target data identifier can be the hash value of some or all of the data in both the target transaction data and the target contract data. This application does not impose any limitations on this. For example, for an electronic bill P, its corresponding data identifier can be the hash value of the entire electronic bill P, i.e., hash(P), or it can be the hash value of specified bill information (such as the bill number) in the electronic bill P. Furthermore, the consensus node can also synchronize the target data identifier of the target business data to the verification node corresponding to the mapping identifier of the node closest to the target data identifier in the addressing direction indicated by the ring mapping space.

[0142] Similarly, for a business object that has acquired target business data, the target business data can be mapped to the ring mapping space through the first business node, and a data location request for the target business data can be sent to the first verification node based on the obtained target data identifier. Therefore, the first verification node can obtain the target data identifier of the target business data from the data location request, and at the same time, it can obtain the first node mapping identifier of the first verification node in the ring mapping space.

[0143] In this context, it can be understood that the node mapping identifier of any verification node is obtained by mapping its node address to the ring mapping space. Taking the first verification node as an example, the first verification node can first obtain its node address as the first node address, and then map this first node address to the ring mapping space to obtain the first node mapping identifier of the first verification node. Specifically, the first node address can be the IP address of the first verification node. Specifically, the first verification node can obtain the hash mapping function (such as SHA-1, SHA256, etc.) associated with the ring mapping space, and then perform a hash operation on the first node address based on this hash mapping function to obtain the first node mapping identifier of the first verification node. The process of obtaining the node mapping identifiers of other verification nodes is similar and will not be elaborated here.

[0144] Optionally, in addition to the IP address of the verification node, the node mapping identifier of the verification node can also be obtained by mapping the node description information of the verification node to the ring mapping space. The node description information here is unique to each verification node, and can be, for example, the node private key of the verification node.

[0145] Step S103: In the addressing direction indicated by the ring mapping space, the target data identifier is checked by the resource location table associated with the first node address of the first node mapping identifier to obtain the first data check result.

[0146] It is understood that each verification node in the verification network can maintain a list of predecessor nodes and a list of successor nodes associated with its own node address, so as to quickly locate predecessor nodes and successor nodes and periodically check the health status of predecessor nodes and successor nodes. Since the addressing process in this embodiment of the application is carried out in the addressing direction indicated by the ring mapping space, the list of successor nodes maintained by the first verification node can be used as a resource location table associated with the first node address of the first verification node. Based on this, the first verification node can perform data verification on the target data identifier by comparing it with the resource location table, thereby obtaining the first data verification result.

[0147] In this embodiment, the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table can be used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network. Here, the neighboring node address is the node address located after the first node address in the addressing direction. That is, the verification node corresponding to the neighboring node mapping identifier stored in the resource location table is the successor node of the first verification node, and the synchronization data identifier of the on-chain synchronization data information stored at its corresponding neighboring node address can refer to the data identifier of the business data addressed by the successor node. It can be understood that the synchronization data identifier can be synchronized by the consensus node to these successor nodes. For ease of understanding, please refer to the above. Figure 2 As shown in the resource location table 201e, it can be seen that the resource location table 201e indicates the four successor nodes of the verification node corresponding to the identifier N8 (i.e., the verification nodes corresponding to identifiers N14, N21, N32 and N38). Among them, the verification node corresponding to identifier N14 also stores the synchronization data identifiers of five on-chain synchronization data information (i.e., identifiers E1 to E5).

[0148] Understandably, if the first verification node wants to find the target business data with the aforementioned target data identifier, after obtaining the first node mapping identifier and the target data identifier, the first verification node can first query whether the next verification node in the addressing direction indicated by the ring mapping space (i.e., the direct successor node of the first verification node) holds the target data identifier currently being searched. If it does, the search ends; otherwise, the addressing can continue.

[0149] In one implementation, the first verification node can obtain the neighboring node mapping identifiers contained in the resource location table associated with the first node address of the first node mapping identifier in the addressing direction indicated by the ring mapping space (such as clockwise direction), and then determine the target neighboring node mapping identifier from the obtained neighboring node mapping identifiers; furthermore, the first verification node can perform data verification on the target data identifier based on the first node mapping identifier and the target neighboring node mapping identifier, thereby obtaining the first data verification result.

[0150] Assuming the resource location table contains N neighboring node mapping identifiers (i.e., the resource location table stores the node mapping identifiers of the N successor nodes of the first verification node), where N is a positive integer greater than 1, the specific process of determining the target neighboring node mapping identifier from the neighboring node mapping identifiers contained in the resource location table can be as follows: Among the N neighboring node mapping identifiers, the first verification node can search for the neighboring node mapping identifier corresponding to the first node address located after the first node address in the addressing direction, and can use the found neighboring node mapping identifier as the first neighboring node mapping identifier; thus, the first neighboring node can be obtained. The node status of the first nearest verification node (i.e., the direct successor node of the first verification node) corresponding to the mapping identifier can be optionally determined as follows: If the node status of the first nearest verification node is valid, it indicates that the first nearest verification node is online normally, and the first nearest node mapping identifier can be used as the target nearest node mapping identifier; alternatively, if the node status of the first nearest verification node is invalid, it indicates that the first nearest verification node has failed (e.g., due to power outage or network failure), and the target nearest node mapping identifier can be determined from (N-1) nearest node mapping identifiers other than the first nearest node mapping identifier. In other words, when the direct successor node of the first verification node fails, other successor nodes in the resource location table, excluding the direct successor node, can be tried sequentially to verify the target data identifier. For example, similarly, the above (N-1) neighboring node mapping identifiers include the second neighboring node mapping identifier corresponding to the first node address located after the node address corresponding to the first neighboring node mapping identifier in the addressing direction. At this time, the first verification node can obtain the node status of the second neighboring verification node corresponding to the second neighboring node mapping identifier. Optionally, if the node status of the second neighboring verification node is valid, the second neighboring node mapping identifier can be used as the target neighboring node mapping identifier; or, optionally, if the node status of the second neighboring verification node is invalid, a similar method can be used to determine the target neighboring node mapping identifier from the remaining neighboring node mapping identifiers (if any) other than the first and second neighboring node mapping identifiers.

[0151] For better understanding, please refer to the above again. Figure 2 ,by Figure 2Taking resource location table 201e as an example, assuming the first node mapping identifier of the first verification node is identifier N8, the resource location table 201e associated with the node address of identifier N8 (i.e., the first node address) contains four neighboring node mapping identifiers (i.e., N=4), namely identifier N14, identifier N21, identifier N32, and identifier N38. It can be seen that the neighboring node mapping identifier corresponding to the first node address after the node address of identifier N8 in the addressing direction is identifier N14. That is, the verification node corresponding to identifier N14 is the direct successor node of the verification node corresponding to identifier N8. Therefore, when the verification node corresponding to identifier N14 is valid, identifier N14 can be used as the target neighboring node mapping identifier. Optionally, when the verification node corresponding to identifier N14 fails, the target neighboring node mapping identifier can be determined from the remaining three neighboring node mapping identifiers (including identifiers N21, N32, and N38).

[0152] It is understood that, after determining the target neighbor node mapping identifier, for ease of distinction, the neighbor node address corresponding to the target neighbor node mapping identifier can be called the target neighbor node address. The synchronization data identifier of the above-mentioned on-chain synchronized data information may include the target synchronization data identifier of the target on-chain synchronized data information stored at the target neighbor node address. Then, the specific process of data verification of the target data identifier based on the first node mapping identifier and the target neighbor node mapping identifier can be as follows: Optionally, if the target data identifier is located within the spatial range determined by the first node mapping identifier and the target neighbor node mapping identifier, it can be determined that the target neighbor node mapping identifier is the node mapping identifier closest to the target data identifier in the addressing direction (at this time, the target neighbor node mapping identifier is greater than or equal to the target data identifier). That is, at this time, the verification node corresponding to the target neighbor node mapping identifier is responsible for addressing the target business data, and it can be determined that the target synchronization data identifier synchronized from the blockchain by the verification node contains the currently searched target data identifier; or, optionally, if the target data identifier is located outside the spatial range determined by the first node mapping identifier and the target neighbor node mapping identifier, it can be determined that the target data identifier is not included in the above-mentioned target synchronization data identifier. Ultimately, the first verification node can use the data verification result when the target synchronization data identifier contains the target data identifier or when the target synchronization data identifier does not contain the target data identifier as the first data verification result.

[0153] For better understanding, please refer to the above again. Figure 2Assuming the currently determined target neighbor node mapping identifier is identifier N14, then the node address corresponding to identifier N14 is the target neighbor node address. The synchronization data identifiers (i.e., identifiers E1 to E5) stored at this target neighbor node address are the target synchronization data identifiers. The on-chain synchronization data information 1 to on-chain synchronization data information 5 corresponding to identifiers E1 to E5 are the target on-chain synchronization data information. Furthermore, assuming the first node mapping identifier is identifier N8 and the target data identifier is identifier K24, then the spatial range determined by identifiers N8 and N14 can be represented as (N8, N14]. At this point, it is found that identifier K24 is not within this spatial range. Therefore, it can be determined that identifier K24 is not included in the aforementioned target synchronization data identifiers (i.e., identifiers E1 to E5), and thus, a further search is needed in the addressing direction.

[0154] Optionally, when the first data verification result indicates that the target synchronization data identifier contains the target data identifier, it can be determined that the target neighboring node mapping identifier is the node mapping identifier closest to the target data identifier in the addressing direction. In this case, the first verification node can forward the data location request carrying the target data identifier to the third verification node corresponding to the target neighboring node mapping identifier. This data location request can be used to instruct the third verification node to verify the authenticity of the target business data. For example, please refer again to the above... Figure 2 Assuming the first node mapping identifier is identifier N8, the target data identifier is identifier K10, and the currently determined target neighbor node mapping identifier is identifier N14, it can be found that identifier K10 is located within the spatial range (N8, N14) determined by identifier N8 and identifier N14. That is to say, identifier N14 is the node mapping identifier closest to identifier K10 in the addressing direction. Therefore, the data positioning request can be forwarded to the verification node corresponding to identifier N14 (i.e., the aforementioned third verification node).

[0155] Furthermore, it's understandable that the Chord algorithm relies on the correctness of successor pointers to ensure the overall network correctness. Since nodes may join, leave, or experience anomalies during the querying process, each query node periodically queries its own successor node to determine if its predecessor node has been updated. If so, the query node also updates its own successor node and routing entries. For robustness, each query node, in addition to its node routing list, also stores its own list of N successor nodes (i.e., a resource location table). When a node fails, updates are sent to subsequent nodes based on this list. Based on this, taking the first verification node as an example, the first verification node can periodically query its successor node's predecessor node to see if it needs to update the successor node and the routing entries in the node routing list. Specifically, the first verification node can send a node query request to the first neighboring verification node (i.e., the first verification node's direct successor). This node query request instructs the first neighboring verification node to return the predecessor node's mapping identifier corresponding to the first node address preceding the node address corresponding to the first neighboring node's mapping identifier in the addressing direction. In other words, the first neighboring verification node needs to return the node mapping identifier of its direct predecessor node to the first verification node. Furthermore, if the first verification node detects that the predecessor node's mapping identifier is different from its own node mapping identifier, it can update the resource location table and node routing list maintained by the first verification node based on the predecessor node's mapping identifier. Therefore, during the verification process, the Chord protocol can provide functions such as automated node online / offline status, data maintenance, and data addressing routing in the verification network, thereby ensuring the integrity and availability of the entire verification network.

[0156] For better understanding, please refer to the above again. Figure 2Suppose a new verification node (referred to as the new verification node) is added to the verification network, and its node mapping identifier is N26. First, the new verification node can point to its successor node (i.e., the verification node corresponding to identifier N32), and then notify the verification node corresponding to N32. After receiving the notification, the verification node corresponding to N32 can mark the new verification node as its predecessor node. Subsequently, both the new verification node and the verification node corresponding to identifier N32 can modify their respective node routing lists. Assuming the node mapping identifier of the first verification node is identifier N21, when the first verification node queries whether the direct predecessor of its direct successor node (i.e., the verification node corresponding to identifier N32, i.e., the aforementioned first neighboring verification node) is still itself, it finds that the direct predecessor of the verification node corresponding to N32 is already the verification node corresponding to identifier N26. At this time, the first verification node can change its direct successor node to the verification node corresponding to identifier N26 and notify the verification node corresponding to identifier N26 that it has set it as its successor node. After receiving the notification, the verification node corresponding to identifier N26 sets the verification node corresponding to identifier N21 as its predecessor node.

[0157] Step S104: When the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the on-chain synchronization data information, in the node routing list maintained by the first verification node, the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction is taken as the second node mapping identifier, and the data positioning request carrying the target data identifier is forwarded to the second verification node corresponding to the second node mapping identifier.

[0158] It is understood that when the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the on-chain synchronization data information, the first verification node can continue to perform addressing through its maintained node routing list until it finds the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction. The found node mapping identifier is then used as the second node mapping identifier, and the data location request carrying the target data identifier can be forwarded to the second verification node corresponding to the second node mapping identifier for verification.

[0159] Here, it is assumed that the above node routing list contains K routing node mapping identifiers, where K is a positive integer greater than 1 and less than or equal to the spatial size parameter of the ring mapping space. This spatial size parameter can be used to indicate the size of the ring mapping space; for example, in a ring mapping space with a size of 2... mWhen the spatial dimension parameter is m, the embodiment of this application adopts a non-linear search method (or a scalable resource location method) to improve addressing efficiency. Specifically, among the K routing node mapping identifiers, the first verification node can first find the routing node mapping identifier that is the largest distance from the first node mapping identifier, and can use the found routing node mapping identifier as the first routing node mapping identifier. Optionally, if the first routing node mapping identifier is located within the spatial range determined by the first node mapping identifier and the target data identifier, the first routing node mapping identifier can be determined as the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction (at this time, the first routing node mapping identifier is smaller than the target data identifier), that is, it means that the verification node corresponding to the first routing node mapping identifier is the predecessor node closest to the target data identifier in the above node routing list. At this time, the first routing node mapping identifier can be used as the second node mapping identifier. Alternatively, if the first routing node mapping identifier is located outside the spatial range determined by the first node mapping identifier and the target data identifier, the second node mapping identifier can be determined from the (K-1) routing node mapping identifiers other than the first routing node mapping identifier. Similarly, among the aforementioned (K-1) routing node mapping identifiers, the first verification node can find the routing node mapping identifier that is furthest from the first routing node mapping identifier, and can use the found routing node mapping identifier as the second routing node mapping identifier. Optionally, if the second routing node mapping identifier is located within the spatial range determined by the first routing node mapping identifier and the target data identifier, then the second routing node mapping identifier can be determined as the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction, and in this case, the second routing node mapping identifier can be used as the second routing node mapping identifier. Alternatively, if the second routing node mapping identifier is located outside the spatial range determined by the first routing node mapping identifier and the target data identifier, a similar method can be used to determine the second routing node mapping identifier from the remaining routing node mapping identifiers (if any) other than the first and second routing node mapping identifiers. In other words, the first verification node can search from far to near in the node routing list. Since its search process converges very quickly, it can effectively reduce search time and reduce routing complexity.

[0160] For better understanding, please refer to the above again. Figure 2 ,by Figure 2Taking the node routing list 201g as an example, assuming the first node mapping identifier of the first verification node is identifier N8, and the target data identifier is identifier K38, the node routing list 201g maintained by the first verification node corresponding to identifier N8 contains 6 routing node mapping identifiers (i.e., identifiers N14, N14, N14, N21, N32, and N42). Duplicate routing node mapping identifiers are allowed. It can be observed that the routing node mapping identifier with the largest distance from identifier N8 in the node routing list 201g is identifier N42 (i.e., the first routing node mapping identifier). It can be understood that in this case, the routing entry N8+32—N42 does not satisfy the condition that identifier N42 is within the spatial range (N8, K38], indicating that identifier N42 is not in the reverse direction of the addressing. The node mapping identifier closest to identifier K38 in the direction. Further, the first verification node can continue searching among the remaining 5 routing node mapping identifiers (i.e., identifiers N14, N14, N14, N21, and N32). It can be found that the routing node mapping identifier with the largest distance to identifier N8 is identifier N32 (i.e., the second routing node mapping identifier). Furthermore, the routing entry N8+16—N32 satisfies that identifier N32 is located within the spatial range (N8, K38), indicating that identifier N32 is the node mapping identifier closest to identifier K38 in the reverse direction of the addressing direction. Therefore, identifier N32 can be used as the second node mapping identifier. Further, the first verification node can forward the data location request carrying identifier K38 to the verification node corresponding to identifier N32 (i.e., the second verification node).

[0161] It is understandable that, after addressing, if the second node mapping identifier of the second verification node is found to be the node mapping identifier closest to the target data identifier in the addressing direction, then the second verification node can further verify the authenticity of the target business data. The specific verification process can be found below. Figure 4 The relevant descriptions in the corresponding embodiments will not be elaborated here.

[0162] It should be noted that the embodiments of this application involve the calculation of the distance between different identifiers. It can be understood that since the data identifier and the node mapping identifier are hash values ​​with the same length, the hash distance between the two identifiers can be determined by performing an XOR operation on the two identifiers. The smaller the difference between the numbers, the smaller the corresponding hash distance.

[0163] As described above, this embodiment of the application, by deploying an verification network in the business network, can support a business object initiating a data location request for a certain business data to any verification node (such as the aforementioned first verification node) in the verification network. The verification node can quickly find the verification node (such as the aforementioned second verification node) corresponding to the node mapping identifier closest to the data identifier of the business data, using the resource location table and node routing list maintained by that verification node. The data location request can then be forwarded to the second verification node, which can continue the search using a non-linear search method similar to the first verification node, until it finds the verification node closest to the target data identifier in the addressing direction within the entire verification network. The finally found verification node can then perform relevant verification on the aforementioned business data. It is understood that compared to point-by-point verification, the non-linear search method used in this embodiment can achieve addressing by jumping to a small number of verification nodes, thereby effectively shortening the addressing distance and improving the addressing efficiency of the verification nodes, thus improving the verification efficiency of business data. Meanwhile, the verification network isolates the core consensus network, which avoids query requests from repeatedly entering the core consensus network and affecting its core performance, while making full use of the computing resources of the business network.

[0164] For further details, please see Figure 4 , Figure 4 This is a flowchart illustrating a data processing method based on a hierarchical chain network provided in an embodiment of this application. Figure 4 As shown, the hierarchical blockchain network includes at least an verification network and a core consensus network. The verification network is deployed within the business network of the hierarchical blockchain network, and the business network is independent of the core consensus network. The M verification nodes in the verification network are composed of the first type of business nodes in the business network. This method can be executed by a second verification node among the M verification nodes; for example, the second verification node can be one of the aforementioned... Figure 1 Any one of the verification nodes (such as verification node 120b) in the verification network 120 shown. Specifically, this method may include the following steps S201-S202:

[0165] Step S201: Obtain the data location request carrying the target data identifier forwarded by the first verification node among the M verification nodes;

[0166] It is understandable, considering the above. Figure 3In the corresponding embodiment, when the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the reverse direction of the addressing direction, it can receive a data location request carrying the target data identifier forwarded by the first verification node. The data location request is a request sent by the service object through the first service node for the target service data corresponding to the target data identifier; the first service node belongs to the second type of service node in the service network; the second type of service node is a service node in the service network other than the first type of service node; the first verification node, when obtaining the target data identifier of the target service data from the data location request, determines the first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network, and, in the addressing direction indicated by the ring mapping space, locates the target data using a resource location table associated with the first node address of the first node mapping identifier. The identifier performs data verification to obtain the first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction; the second node mapping identifier of the second verification node refers to the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction in the node routing list maintained by the first verification node when the first data verification result indicates that the synchronization data identifier of the on-chain synchronization data information does not contain the target data identifier. The specific addressing process on the first verification node can be found above. Figure 3 The corresponding implementation examples will not be described in detail here.

[0167] It is understandable that after receiving the above data location request, the second verification node can also perform a similar addressing process as the first verification node, such as using the resource location table and node routing list maintained by the second verification node for addressing, which will not be elaborated here.

[0168] Step S202: When the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, verify the authenticity of the target business data.

[0169] It is understood that the target business data is determined by the consensus nodes in the core consensus network after they call the target business contract on the blockchain to execute the target transaction. This target business data can be one or more of the following: target transaction data or target contract data associated with the target transaction. Here, the target transaction is initiated by the second business node; the second business node belongs to the second type of business node in the business network. As mentioned above, the verification node can synchronize the data identifier of business data that is close to its node mapping identifier (or address space). In addition, it can synchronize the on-chain verification information of this business data to verify its authenticity. Based on this, the second verification node will be used as an example for explanation. Specifically, when the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, the second verification node can obtain the target data identifier and the on-chain verification information of the target business data from the blockchain. For ease of distinction, the on-chain verification information of the target business data can be referred to as target verification information. Subsequently, the synchronized target data identifier and target verification information can be stored. Optionally, the second verification node can proactively send a data synchronization request to the consensus node. After obtaining the second node mapping identifier of the second verification node from this request, the consensus node can determine the distance between the second node mapping identifier and the target data identifier. If the second node mapping identifier is identified as the node mapping identifier closest to the target data identifier in the addressing direction, the consensus node can return the target data identifier and the target verification information of the corresponding target business data to the second verification node for storage. Alternatively, after the consensus node successfully uploads the target business data to the chain, it can search among the node mapping identifiers of all verification nodes it records for the node mapping identifier closest to the target data identifier in the addressing direction. When the found node mapping identifier is the second node mapping identifier, the consensus node can proactively synchronize the target data identifier and the target verification information of the target business data to the second verification node corresponding to the second node mapping identifier for storage.

[0170] It is understandable that each verification node can provide verification functions externally. Therefore, after addressing is completed, the verification node finally located is the one that stores verification information (e.g., verification information C2) of the business data to be verified (e.g., business data C1). This verification node can perform authenticity verification on business data C1 based on its stored verification information C2. Based on this, when the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, it indicates that the second verification node stores the target verification information of the target business data. Therefore, the second verification node can perform authenticity verification on the target business data based on this target verification information to obtain the second data verification result. Furthermore, the second verification node can return the first verification certificate information corresponding to the target business data to the business object based on the second data verification result.

[0171] In this embodiment, the verification node forms a verification network in the business network using the Chord DHT algorithm structure. It is responsible for synchronizing the on-chain verification information of the business data within the hash space range (i.e., the space range from its predecessor node to the verification node in the ring mapping space) corresponding to its own node mapping identifier (also known as node ID). The on-chain verification information includes, but is not limited to, the Merkle path of the transaction data, the set of node signatures related to the transaction data, time-related information such as data timestamps and validity periods, data details (such as some original information required by the verification node), and additional information required to read the data. Therefore, the authenticity verification in this embodiment can include one or more verification methods, which will be described below.

[0172] Optionally, in one implementation, the target verification information may include a Merkel path associated with the target transaction data. Based on this, the second verification node can obtain the transaction hash value of the target transaction data and the path hash value in the Merkel path, thereby determining the root to be verified based on the transaction hash value of the target transaction data and the path hash value in the Merkel path. Further, the second verification node can synchronize the block header information of the target block where the target transaction data is located, thereby obtaining the Merkel root in the block header information. Subsequently, the root to be verified can be compared with the Merkel root to obtain the root verification result. It can be understood that if the root verification result indicates that the root to be verified is consistent with the Merkel root, the second verification node can determine that the root verification is successful; conversely, if the root verification result indicates that the root to be verified is inconsistent with the Merkel root, the second verification node can determine that the root verification has failed. The second verification node can then determine the second data verification result based on the root verification result.

[0173] Optionally, in one implementation, the target verification information may include a set of node signatures associated with the target block containing the target transaction data. This set of node signatures may include node signature information obtained by each of the G consensus nodes in the core consensus network signing the target block, where G is a positive integer. Here, the G consensus nodes can form a consensus node committee, and the node signature set can also be called the consensus node committee signature set (Quorum Certification, or QC). This set of node signatures may include node signature information obtained by each of the G consensus nodes participating in the consensus process, after signing the target block using their respective node private keys. Based on this, the second verification node can obtain the node public keys corresponding to the G consensus nodes, and then perform node signature verification on the node signature information in the node signature set based on the obtained G node public keys, thereby obtaining the node signature verification result.

[0174] It's understandable that the public key of a consensus node can be used to verify the signature information of one node in the node signature set. For ease of understanding, let's take verifying one node signature Q as an example: During the process of packaging the target block onto the chain, consensus node P can perform a hash operation on all block content (including the block header and block body) or part of the block content (e.g., the block body) to obtain the digest information H of the target block. Then, based on the private key of consensus node P, it can digitally sign this digest information H to obtain the node signature information Q corresponding to the target block. Further, when the second verifying node obtains the node signature information Q of the target block, it can obtain the public key of consensus node P, and then perform node signature verification on the node signature information Q based on this public key to obtain the corresponding sub-verification result. In this context, it can be understood that the second verification node can verify the digital signature in the signature information Q of the consensus node P based on the node's public key, obtaining the digest information H of the target block. It can then use the same hash algorithm as the consensus node P to perform a hash operation on the same block content within the target block, thereby obtaining the digest information h of the target block. Further, the second verification node can compare the digest information H obtained after verification with the digest information h obtained from the hash operation to obtain a sub-verification result. If the sub-verification result indicates that the digest information H and digest information h are different, it can be understood that the node signature information Q has failed to be verified; if the sub-verification result indicates that the digest information H and digest information h are the same, it can be understood that the node signature information Q has been successfully verified.

[0175] It is understandable that after verifying the signatures of all G nodes in the node signature set, a sub-verification result corresponding to each node signature can be obtained. These G sub-verification results are used as the node verification result. Specifically, when all G sub-verification results indicate successful verification, the second verification node can determine that the node signature set has been successfully verified, indicating that the block content in the target block has not been maliciously tampered with and is authentic and valid. When any of the G sub-verification results indicates verification failure, the second verification node can determine that the node signature set has failed verification. Subsequent second verification nodes can then determine the second data verification result based on this node verification result.

[0176] Optionally, in one implementation, the target verification information may include first time-related information associated with the target transaction data. This first time-related information may include the data timestamp of the target transaction data. This data timestamp can be the transaction timestamp of the target transaction data, a timestamp present in the data content of the target transaction data (e.g., the invoice date in an electronic invoice), or other verifiable timestamps. This application embodiment does not limit this. Based on this, the second verification node can obtain the timestamp to be verified of the target transaction data from the received data location request, and then compare the timestamp to be verified with the data timestamp to obtain the timestamp verification result. It can be understood that if the timestamp verification result indicates that the timestamp to be verified is consistent with the data timestamp, the second verification node can determine that the timestamp verification is successful, and the target transaction data is indeed transaction data at a certain moment; conversely, if the timestamp verification result indicates that the timestamp to be verified is inconsistent with the data timestamp, the second verification node can determine that the timestamp verification has failed, and the target transaction data may have been tampered with or updated. Subsequently, the second verification node can determine the second data verification result based on the timestamp verification result.

[0177] Optionally, in one implementation, the target verification information may include second time-related information associated with the target contract data. This second time-related information may include the certificate validity period corresponding to the public key certificate of the consensus node in the core consensus network. As mentioned above, when the second verification node verifies the node signature information in the node signature set, it needs to obtain the node public key of the consensus node. The node public key can be obtained by synchronizing the public key certificate of the consensus node. Therefore, the validity of the public key certificate needs to be verified before using the node public key. Based on this, the second verification node can use the public key certificate of the consensus node synchronized from the blockchain as the first public key certificate. This first public key certificate contains the node public key used for node signature verification of the node signature set associated with the target block where the target transaction data is located. Furthermore, the second verification node can obtain the usage period of the first public key certificate and then compare the usage period of the first public key certificate with the certificate validity period to obtain the certificate validity verification result. It is understandable that, optionally, if the certificate validity verification result indicates a usage duration greater than or equal to the certificate's validity period, the second verification node can determine that the first public key certificate is invalid. In this case, the second verification node can request the consensus node to update the certificate. Alternatively, optionally, if the certificate validity verification result indicates a usage duration less than the certificate's validity period, the second verification node can determine that the first public key certificate is valid. Subsequently, the second verification node can determine the second data verification result based on this certificate validity verification result. Furthermore, the second time-related information here can also include the validity period of some data states, which can also be verified. These data states may change, and after expiration, the state can be updated from the smart contracts deployed on the blockchain (such as the target business contract).

[0178] It is understood that the aforementioned first-time association information and second-time association information are both time-related information associated with the target business data. Other time-related information can also be used for relevant verification, which is not limited here.

[0179] Furthermore, it is understandable that if specific data is allowed to be verified, the corresponding business node will register its own node address (such as an IP address) on the chain and authorize the visibility of its business data. The consensus node can also update these node addresses registered on the chain in real time. Correspondingly, the verification nodes in the verification network will store the node address corresponding to each data hash item (i.e., data identifier) ​​(i.e., the node address storing the business data corresponding to that data identifier). When original text verification is required, the verification node will access the specific business node. Based on this, taking the aforementioned second business node as an example, the second business node stores the original text information of the target business data synchronized from the consensus node. This original text information can be the specific original content of the target business data (such as certain fields, official seals, signatures, images, etc.), rather than the processed overall hash value. For example, the original text information of an electronic ticket may include its ticket number, header, etc. Since the original text information is private data, the ability to provide original text verification is only provided after authorization from the data holder (i.e., the second business node). Assuming the target verification information includes additional reading information, this additional reading information is determined by the consensus node calling the target business contract to register permissions for the original authorization information submitted by the second business node. In other words, if the original data information of the target business data authorized by the second business node is visible and verifiable, then the second business node can submit the original authorization information to the consensus node. This original authorization information may include the second business node's node address and verification configuration information, allowing the consensus node to register its own node address in the target business contract and set its data to be verifiable. The additional reading information can be any additional information needed when reading data from the second business node. For example, if the second business node has set up a large amount of verifiable business data, blindly searching might be difficult. In this case, the additional reading information can be used to find the specific data original information within a certain time period or region indicated by the time or region range. The additional reading information may also include other additional information, the specific content of which is not limited here.

[0180] Understandably, when the aforementioned authenticity verification includes original text verification of the target business data, the second verification node can obtain the address of the business node storing the original text information of the target business data. Then, based on the read supplementary information, it can send an original text verification request for the target business data to the second business node corresponding to the business node address. Correspondingly, upon receiving the original text verification request, the second business node can determine the original text information of the target business data based on the read supplementary information, and perform original text verification on the target business data based on this original text information, thereby obtaining a third data verification result. Furthermore, it can return the second verification certificate information corresponding to the target business data to the business object based on the third data verification result. For example, for an electronic ticket C, when it is necessary to verify its ticket number, business node 1 can obtain the ticket number to be verified from the relevant original text verification request, and can obtain the original text of the ticket number from the synchronized original text information based on the read supplementary information. Then, it can compare the ticket number to be verified with the original text of the ticket number to obtain the corresponding data verification result.

[0181] Alternatively, the second verification node can return the aforementioned business node address to the business object, and then the business object can re-initiate a plaintext verification request for the target business data to the second business node corresponding to that business node address through the first business node.

[0182] Furthermore, it is understood that if the entire addressing process ultimately fails to find a verification node storing the target verification information among the aforementioned M verification nodes, the data location request carrying the target data identifier can be forwarded to a consensus node in the core consensus network, allowing the consensus node to verify the authenticity of the target business data. It is understood that each consensus node is a full node, storing the required target verification information, thus verifying the authenticity of the target business data without addressing. Therefore, the verification network in this embodiment isolates the core consensus network, preventing query-type requests from repeatedly entering the core consensus network and thus affecting its core performance, while fully utilizing the computing resources of the business network.

[0183] Understandably, considering reliability, consensus nodes can also send the verification information of the same business data to the 2-3 verification nodes closest to the hash distance of the data identifier of that business data for backup storage. This way, if the nearest verification node fails or its stored verification information is corrupted, it can attempt to search from other verification nodes that have backed up the verification information. Taking the second verification node as an example, if the second verification node is in a failed state or the target verification information stored by the second verification node is incomplete, it can forward a data location request carrying the target data identifier to the fourth verification node. Here, the node mapping identifier of the fourth verification node is the node mapping identifier closest to the target data identifier in the addressing direction, excluding the second node mapping identifier, and the fourth verification node is used to back up the target verification information. It can be understood that this data location request can be used to instruct the fourth verification node to perform authenticity verification on the target business data based on its backed-up target verification information. Therefore, even if some business nodes fail and original verification cannot be performed, the verification network can still ensure that business data and historical data are verifiable in the long term through the backup storage of several verification nodes.

[0184] Furthermore, the embodiments of this application can also provide a data maintenance function for the verification network. Taking the second verification node as an example, specifically, the verifiable timestamp (e.g., timestamp T1) of the target business data can be determined through the target business contract (e.g., electronic bill contract). Further, the second verification node can obtain the verification time limit event generated by the consensus node based on the verifiable timestamp of the target business data. When the verifiable timestamp in the verification time limit event is obtained, if the data timestamp (e.g., timestamp T2) of the target business data is detected to be earlier than the verifiable timestamp, the second verification node can determine that the target business data can no longer be verified. At this time, the target data identifier and target verification information stored by the second verification node can be cleared. For example, suppose the electronic bill contract in the blockchain electronic bill system determines that the verifiability period of the electronic bill is 3 years, meaning that electronic bills within 3 years can be verified. Then, the consensus node will periodically broadcast the corresponding verification period event D1. The verification node D3, which is responsible for verifying electronic bill D2, can determine the verifiability timestamp of electronic bill D2 based on the verifiability period in the verification period event D1. For example, suppose the verifiability timestamp is January 1, 2020, and the invoice date of electronic bill D2 is December 1, 2019. Then, the verification node D3 can clear the data identifier and verification information related to electronic bill D2.

[0185] As described above, the addressing algorithm used in this application embodiment can achieve addressing by jumping to a small number of verification nodes, thereby improving the addressing efficiency of verification nodes and thus improving the verification efficiency of business data. After successful addressing, the finally located verification node can verify the authenticity of the business data and can access relevant business nodes when the original text needs to be verified. This separates the verification network from the business SPV nodes, providing a stable blockchain data verification service while ensuring the privacy of business data. In addition, during the verification process, the Chord protocol can provide functions such as automatic node online / offline status, data maintenance, and data addressing routing in the verification network, ensuring the integrity and availability of the entire verification network. Even if the business SPV node fails, the verification network can still ensure that business data and historical data are verifiable and searchable for a long time.

[0186] For better understanding, please refer to [link / reference]. Figure 5 , Figure 5 This is a schematic diagram illustrating a scenario for verifying blockchain electronic invoices, as provided in an embodiment of this application. Figure 5 The service node 50A shown can serve as the aforementioned second service node; for example, the service node 50A can be the aforementioned... Figure 1 The business execution network 110 shown can be any business node; consensus node 50B can be any consensus node in the core consensus network 200a; verification node 50C can be any of the above-mentioned second verification nodes, for example, the verification node 50C can be any of the above-mentioned... Figure 1 Any verification node in the verification network 120 shown. For example... Figure 5 As shown, assuming that business node 50A obtains electronic invoice X (i.e., the aforementioned target business data) after executing the invoice issuance business, and hash(X) = y, that is, the data identifier of electronic invoice X is y (i.e., the aforementioned target data identifier), then after consensus node 50B writes electronic invoice X into the corresponding blockchain, it can asynchronously synchronize the verification information 501a of electronic invoice X on the blockchain (i.e., the aforementioned target verification information, which may include the Merkel path associated with electronic invoice X, node signature set, etc.) to the verification node 50C with the closest hash distance and y through the P2P network. That is, at this time, the node mapping identifier of verification node 50C is the node mapping identifier with the closest distance to y in the addressing direction indicated by the corresponding ring mapping space. Verification node 50C can then store the verification information 501a. It can be understood that, considering reliability, in addition to verification node 50C, consensus node 50B will send the verification information 501a to the 2 to 3 verification nodes with the closest hash distance and y (i.e., the aforementioned fourth verification node) for backup storage. For business node 50A, it will only synchronize the original data information 501b of electronic invoice X (such as the ticket number and header of electronic invoice X).

[0187] Further, please see Figure 6 , Figure 6 This is a schematic diagram illustrating a scenario for verifying blockchain electronic invoices, as provided in an embodiment of this application. Figure 6 As shown, in conjunction with the aforementioned Figure 5 In the corresponding embodiment, assuming user A (i.e., the aforementioned business object) has obtained electronic invoice X and wants to verify the authenticity of electronic invoice X on the blockchain, then business node 50D can send a data location request for electronic invoice X to verification node 50E in the verification network, that is, entrusting verification node 50E to provide proof of the authenticity of electronic invoice X to user A. Here, business node 50D can serve as the aforementioned first business node; for example, business node 50D can be the aforementioned... Figure 1 Any service node in the service execution network 110 shown; the verification node 50E can be the first verification node mentioned above, for example, the verification node 50E can be the aforementioned Figure 1 Any of the verification nodes in the verification network 120 shown.

[0188] It is understandable that after receiving the data location request of electronic ticket X, verification node 50E can use the data identifier (i.e., hash(X)) of electronic ticket X for addressing, thereby finding verification node 50C that stores the verification information 501a of electronic ticket X in the verification network, and then forwarding the aforementioned data location request to verification node 50C. The specific addressing process can be found above. Figure 3 The corresponding embodiments will not be described in detail here. Further, the verification node 50C can verify the authenticity of the electronic ticket X based on its stored verification information 501a, and generate verification certificate information 501c corresponding to the electronic ticket X (i.e., the aforementioned first verification certificate information), and then return the verification certificate information 501c to the business node 50D associated with user A. The specific process of authenticity verification can be found above. Figure 4 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0189] It is understandable that verification node 50C can record the node address 501d of the business node 50A corresponding to electronic invoice X (i.e., the aforementioned business node address, for example, the IP address of business node 50A). If business node 50A previously allowed the original text of electronic invoice X to be verified, then the data allowing the verification of the original text has already been registered and set in the corresponding electronic invoice contract. Assuming that the verification of electronic invoice X involves the original text (such as verifying certain fields in the original text, rather than the overall hash value), verification node 50C can jump to business node 50A to perform the relevant verification of the original text. For ease of understanding, please refer to [link to relevant documentation]. Figure 7 , Figure 7 This is a schematic diagram illustrating a scenario for verifying blockchain electronic invoices, as provided in an embodiment of this application. Figure 7 As shown, in conjunction with the aforementioned Figure 5 and Figure 6 In the corresponding embodiment, verification node 50C can send a text verification request for electronic invoice X to business node 50A. Subsequently, business node 50A can perform text verification on electronic invoice X based on the original data information 501b, and can return the verification certificate information 501e corresponding to electronic invoice X to business node 50D associated with user A. The specific process of text verification can be found above. Figure 4 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0190] Furthermore, if no valid verification node is found that stores the verification information 501a of electronic ticket X, the fallback is to request verification of the authenticity of electronic ticket X from a consensus node in the core consensus network (such as the aforementioned consensus node 50B). The consensus node can then use the relevant verification information on the blockchain to verify the authenticity of electronic ticket X.

[0191] It should be noted that the verification network in this embodiment consists of long-term stable online SPV nodes, which can be run by official or authoritative alliance members. Before joining, they must meet conditions such as continuous online status for a certain period of time and ping latency of less than 10ms (i.e., the aforementioned verification network joining conditions). Otherwise, they will only perform ordinary SPV functions and will not join the Chord DHT verification network. In addition, SPV nodes that join the verification network can receive certain verification rewards based on the number of verification services they provide.

[0192] In addition, the verifiability period of electronic tickets can be determined by the electronic ticket contract in the system (e.g., verifiability within 3 years). At this time, the core consensus network will broadcast periodically, and the verification nodes in the verification network can clean up past data according to the verifiability period.

[0193] Therefore, the addressing algorithm used in this application embodiment can achieve addressing by jumping to a small number of verification nodes, thereby improving the addressing efficiency of verification nodes and thus improving the verification efficiency of business data. After successful addressing, the finally located verification node can verify the authenticity of the business data and can access relevant business nodes when the original text needs to be verified. This separates the verification network from the business SPV nodes, providing a stable blockchain data verification service while ensuring the privacy of business data. In addition, during the verification process, the Chord protocol can provide functions such as automatic node online / offline status, data maintenance, and data addressing routing in the verification network, ensuring the integrity and availability of the entire verification network. Even if the business SPV node fails, the verification network can still ensure that business data and historical data are verifiable and searchable for a long time.

[0194] For better understanding, please refer to [link / reference]. Figure 8 , Figure 8 This is a system architecture diagram for a blockchain electronic invoice scenario provided in an embodiment of this application. For example... Figure 8 As shown in the embodiments of this application, the business layer, the routing proxy layer, and the core consensus network layer constitute the entire complete blockchain business system. Figure 8 The core chain 1, core chain 2, ... and core chain N shown are target blockchains maintained by tax authorities in different regions. The business data (e.g., business data Y) in this embodiment may include transaction data and contract data generated during the execution of bill transactions (such as electronic bill transfer transactions).

[0195] It is understandable that when blockchain is used in some scenarios of government agencies (e.g., tax systems) or commercial organizations, in order to improve the confidentiality and security of data, the layered blockchain structure of "business network - core consensus network" (i.e., the aforementioned layered chain network) in this application embodiment can be adopted to adapt to the specific requirements of the actual network layout of the relevant industry blockchain production line (e.g., internal and external networks, separation of business network and office network, etc.), while ensuring the efficient execution of the core consensus algorithm.

[0196] The business layer resides within the witness network (i.e., the business network). Business nodes in this layer can include terminal devices corresponding to the e-tax bureau, terminal devices corresponding to enterprise users, and terminal devices corresponding to consumer users. The e-tax bureau can refer to the local tax bureau within the tax bureau's dedicated network. Enterprise users can be invoicing service providers, reimbursement service providers, or retail enterprises (e.g., KA enterprises, i.e., large retail clients and key retail clients) in the public cloud. Consumer users can be payment service providers, circulation service providers, or retail enterprises in the private cloud. The business nodes in this business network can be divided into two categories: Category 1 business nodes primarily synchronize data identifiers (such as the hash value of the business data) of business data with address spaces similar to their own nodes (indicated by corresponding node mapping identifiers) and provide external verification functions. Category 2 business nodes primarily execute transaction business, do not participate in accounting consensus, and can synchronously clear business data related to themselves.

[0197] In this routing proxy layer, N relay nodes (i.e., routing nodes) can be used to isolate the business layer and the core consensus network layer. Each relay node can provide peer-to-peer (P2P) service, routing service, certificate caching, and authentication service. Peer-to-peer service refers to a service in a P2P network based on a specific network protocol. In a P2P network, network nodes do not require a central node to maintain the network state; instead, each node maintains the overall network state or the connection state of its neighbors through broadcast interactions with neighboring nodes. Routing service is a basic function of nodes and can be used for communication between nodes. Certificates associated with the certificate cache can refer to Public Key Infrastructure (PKI). In a PKI, a certificate is proof of identity for a public key holder, issued by an authoritative authority (Certificate Authority, CA). Authentication service can be used to verify the data format of received data, node legitimacy, etc. In this embodiment, relay nodes can forward transaction data submitted by the second type of business nodes to the consensus node.

[0198] In this context, the consensus nodes (i.e., accounting nodes) in the core consensus network layer can be trusted nodes within the tax-specific network. It is understood that each consensus node has the ability to package and generate blocks; that is, it can package transaction data that has passed consensus into blocks, store related contract data, or package both transaction data and contract data into blocks to successfully write them into the target blockchain in the core consensus network layer.

[0199] Furthermore, an verification network for data verification can be deployed within the business network using first-type business nodes. These first-type business nodes can be referred to as verification nodes. This application provides a Chord-based business data verification scheme. Taking the first verification node in this verification network as an example, the first verification node can obtain a data location request for target business data sent by a business object through the first business node. It can then perform addressing based on the target data identifier of the target business data. During the addressing process, it can utilize its maintained resource location table and node routing list to improve addressing efficiency. Finally, when the second node mapping identifier of the second verification node is found to be the node mapping identifier closest to the target data identifier in the addressing direction, the authenticity of the target business data can be verified through the second verification node. It can be understood that compared to point-by-point verification, the non-linear search method adopted in this application can achieve addressing by jumping to a small number of verification nodes, thereby effectively shortening the addressing distance and improving the addressing efficiency of the verification nodes, thus improving the verification efficiency of business data.

[0200] Please see Figure 9 This is a schematic diagram of a data processing device based on a hierarchical chain network provided in an embodiment of this application. The hierarchical chain network here includes at least a verification network and a core consensus network. The verification network is deployed within the business network of the hierarchical chain network. The business network is independent of the core consensus network, and the M verification nodes in the verification network are composed of the first type of business nodes in the business network, where M is a positive integer. For example... Figure 9 As shown, the data processing device 1 based on the hierarchical blockchain network can be applied to a first verification node, which can be any blockchain node in the verification network (e.g., the verification network 120 mentioned above). Figure 1 The corresponding embodiment refers to the verification node 120a. It should be understood that the data processing device 1 based on the hierarchical blockchain network can be a computer program (including program code) running on a blockchain node (e.g., the aforementioned verification node 120a), for example, the data processing device 1 based on the hierarchical blockchain network is an application software; it is understood that the data processing device 1 based on the hierarchical blockchain network can be used to execute corresponding steps in the data processing method based on the hierarchical blockchain network provided in the embodiments of this application. Figure 9 As shown, the data processing device 1 based on the hierarchical chain network may include: a request acquisition module 11, an identifier determination module 12, an identifier verification module 13, a first forwarding module 14, a second forwarding module 15, and a node change module 16;

[0201] The request acquisition module 11 is used to acquire a data location request for target business data sent by a business object through a first business node; the first business node belongs to the second type of business node in the business network; the second type of business node is a business node in the business network other than the first type of business node.

[0202] The identifier determination module 12 is used to determine the first node mapping identifier of the first inspection node in the ring mapping space corresponding to the inspection network when the target data identifier of the target business data is obtained from the data location request.

[0203] The target data identifier is obtained by mapping the target business data to the ring mapping space corresponding to the verification network.

[0204] The identifier determination module 12 may include: an address acquisition unit 121 and an address mapping unit 122;

[0205] Address acquisition unit 121 is used to acquire the first node address of the first verification node when the target data identifier of the target business data is obtained from the data location request.

[0206] Address mapping unit 122 is used to map the address of the first node to the ring mapping space to obtain the first node mapping identifier of the first verification node;

[0207] The address mapping unit 122 is specifically used to obtain the hash mapping function associated with the ring mapping space, perform a hash operation on the address of the first node based on the hash mapping function, and obtain the first node mapping identifier of the first verification node; the hash mapping function is also used to perform a hash operation on the target business data to obtain the target data identifier of the target business data.

[0208] The specific implementation methods of the address acquisition unit 121 and the address mapping unit 122 can be found in the above description. Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0209] The identifier verification module 13 is used to perform data verification on the target data identifier in the addressing direction indicated by the ring mapping space through the resource location table associated with the first node address of the first node mapping identifier, and obtain the first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction;

[0210] The identification verification module 13 may include: an identification acquisition unit 131 and an identification verification unit 132;

[0211] The identifier acquisition unit 131 is used to acquire, in the addressing direction indicated by the ring mapping space, the neighboring node mapping identifier contained in the resource location table associated with the first node address of the first node mapping identifier, and determine the target neighboring node mapping identifier in the neighboring node mapping identifier.

[0212] The number of neighboring node mapping identifiers is N; N is a positive integer greater than 1.

[0213] The identifier acquisition unit 131 may include: an identifier lookup subunit 1311, a first identifier determination subunit 1312, and a second identifier determination subunit 1313;

[0214] The identifier lookup subunit 1311 is used to find the neighboring node mapping identifier corresponding to the first node address located after the first node address in the addressing direction among N neighboring node mapping identifiers, and use the found neighboring node mapping identifier as the first neighboring node mapping identifier.

[0215] The first identifier determination subunit 1312 is used to obtain the node status of the first neighboring verification node corresponding to the first neighboring node mapping identifier. If the node status of the first neighboring verification node is valid, the first neighboring node mapping identifier is used as the target neighboring node mapping identifier.

[0216] The second identifier determination subunit 1313 is used to determine the target neighboring node mapping identifier from (N-1) neighboring node mapping identifiers other than the first neighboring node mapping identifier if the node status of the first neighboring inspection node is in an invalid state.

[0217] The specific implementation methods of the identifier lookup subunit 1311, the first identifier determination subunit 1312, and the second identifier determination subunit 1313 can be found in the above description. Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0218] The identifier verification unit 132 is used to perform data verification on the target data identifier based on the first node mapping identifier and the target neighboring node mapping identifier, and obtain the first data verification result.

[0219] Among them, the synchronization data identifier of the on-chain synchronization data information includes the target synchronization data identifier of the target on-chain synchronization data information stored at the target neighbor node address corresponding to the target neighbor node mapping identifier;

[0220] The identification verification unit 132 may include: a first addressing subunit 1321, a second addressing subunit 1322, and a result determination subunit 1323;

[0221] The first addressing subunit 1321 is used to determine, if the target data identifier is located within the spatial range determined by the first node mapping identifier and the target neighboring node mapping identifier, that the target neighboring node mapping identifier is the node mapping identifier closest to the target data identifier in the addressing direction, and to determine that the target synchronization data identifier contains the target data identifier.

[0222] The second addressing subunit 1322 is used to determine that the target data identifier is not included in the target synchronization data identifier if the target data identifier is located outside the spatial range determined by the first node mapping identifier and the target neighboring node mapping identifier.

[0223] The result determination subunit 1323 is used to take the data verification result when the target synchronization data identifier contains the target data identifier or when the target synchronization data identifier does not contain the target data identifier as the first data verification result.

[0224] The specific implementation methods of the first addressing subunit 1321, the second addressing subunit 1322, and the result determination subunit 1323 can be found in the above description. Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0225] The specific implementation methods of the identifier acquisition unit 131 and the identifier verification unit 132 can be found in the above description. Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0226] The first forwarding module 14 is used to, when the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the on-chain synchronization data information, select the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction from the node routing list maintained by the first verification node as the second node mapping identifier, and forward the data positioning request carrying the target data identifier to the second verification node corresponding to the second node mapping identifier; when the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, the second verification node is used to verify the authenticity of the target business data;

[0227] The node routing list contains K routing node mapping identifiers; K is a positive integer greater than 1 and less than or equal to the spatial size parameter of the ring mapping space;

[0228] The first forwarding module 14 may include: an identifier lookup unit 141, a first identifier determination unit 142, and a second identifier determination unit 143;

[0229] The identifier lookup unit 141 is used to find the routing node mapping identifier that is the largest distance from the first node mapping identifier among the K routing node mapping identifiers, and to use the found routing node mapping identifier as the first routing node mapping identifier.

[0230] The first identifier determination unit 142 is configured to determine the first routing node mapping identifier as the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction if the first routing node mapping identifier is located within the spatial range determined by the first node mapping identifier and the target data identifier, and to use the first routing node mapping identifier as the second node mapping identifier.

[0231] The second identifier determination unit 143 is used to determine the second node mapping identifier from (K-1) routing node mapping identifiers other than the first routing node mapping identifier if the first routing node mapping identifier is located outside the spatial range determined by the first node mapping identifier and the target data identifier.

[0232] The specific implementation methods of the identifier lookup unit 141, the first identifier determination unit 142, and the second identifier determination unit 143 can be found in the above description. Figure 3The description of step S104 in the corresponding embodiment will not be repeated here.

[0233] The second forwarding module 15 is used to forward a data location request carrying the target data identifier to the third verification node corresponding to the target neighbor node mapping identifier when the first data verification result indicates that the target synchronization data identifier contains the target data identifier; the data location request is used to instruct the third verification node to verify the authenticity of the target business data.

[0234] The node change module 16 is used to send a node query request to the first neighboring verification node. The node query request is used to instruct the first neighboring verification node to return the predecessor node mapping identifier corresponding to the first node address located in the addressing direction that is preceding the node address corresponding to the first neighboring node mapping identifier. If the predecessor node mapping identifier is different from the first node mapping identifier, the resource location table and the node routing list maintained by the first verification node are updated based on the predecessor node mapping identifier.

[0235] The specific implementation methods of the request acquisition module 11, the identifier determination module 12, the identifier verification module 13, the first forwarding module 14, the second forwarding module 15, and the node change module 16 can be found in the above description. Figure 3 The descriptions of steps S101-S104 in the corresponding embodiments will not be repeated here. It should be understood that the descriptions of the beneficial effects obtained by using the same method will also not be repeated.

[0236] Please see Figure 10 This is a schematic diagram of a data processing device based on a hierarchical chain network provided in an embodiment of this application. The hierarchical chain network here includes at least a verification network and a core consensus network. The verification network is deployed within the business network of the hierarchical chain network. The business network is independent of the core consensus network, and the M verification nodes in the verification network are composed of the first type of business nodes in the business network, where M is a positive integer. For example... Figure 10 As shown, the data processing device 2 based on the hierarchical blockchain network can be applied to a second verification node, which can be any blockchain node in the verification network (e.g., the verification network 120 mentioned above). For example, the second verification node can be any of the blockchain nodes in the aforementioned network. Figure 1 The corresponding embodiment refers to the verification node 120b. It should be understood that the data processing device 2 based on the hierarchical blockchain network can be a computer program (including program code) running on a blockchain node (e.g., the aforementioned verification node 120b), for example, the data processing device 2 based on the hierarchical blockchain network is an application software; it is understood that the data processing device 2 based on the hierarchical blockchain network can be used to execute the corresponding steps in the data processing method based on the hierarchical blockchain network provided in the embodiments of this application. Figure 10As shown, the data processing device 2 based on the hierarchical chain network may include: a request receiving module 21, an authenticity verification module 22, a data synchronization module 23, a original text verification module 24, a third forwarding module 25, a fourth forwarding module 26, and a data clearing module 27.

[0237] Request receiving module 21 is used to obtain a data location request carrying a target data identifier forwarded by the first verification node among M verification nodes; the data location request is a request sent by a service object through the first service node for the target service data corresponding to the target data identifier; the first service node belongs to the second type of service node in the service network; the second type of service node is a service node in the service network other than the first type of service node; the first verification node is used to determine the first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network when it obtains the target data identifier of the target service data from the data location request, and is used to map the first node in the addressing direction indicated by the ring mapping space. The resource location table associated with the first node address of the identifier performs a data verification on the target data identifier to obtain the first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction; the second node mapping identifier of the second verification node refers to the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction in the node routing list maintained by the first verification node when the first data verification result indicates that the synchronization data identifier of the on-chain synchronization data information does not contain the target data identifier;

[0238] The authenticity verification module 22 is used to verify the authenticity of the target business data when the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction;

[0239] The authenticity verification module 22 may include: an authenticity verification unit 221 and a proof return unit 222;

[0240] The authenticity verification unit 221 is used to perform authenticity verification on the target business data based on the target verification information when the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, and obtain the second data verification result.

[0241] The authenticity verification unit 221 may include: root verification subunit 2211, signature verification subunit 2212, timestamp verification subunit 2213, and certificate verification subunit 2214.

[0242] In one implementation, the target verification information includes a Merkel path associated with the target transaction data;

[0243] The root verification subunit 2211 is used to obtain the transaction hash value of the target transaction data, determine the root to be verified based on the transaction hash value and Merkel path of the target transaction data, obtain the Merkel root in the block header information of the target block where the target transaction data is located, compare the root to be verified with the Merkel root to obtain the root verification result, and determine the second data verification result based on the root verification result.

[0244] In one implementation, the target verification information includes a set of node signatures associated with the target block where the target transaction data is located; the set of node signatures includes node signature information obtained by each of the G consensus nodes in the core consensus network signing the target block; G is a positive integer;

[0245] The signature verification subunit 2212 is used to obtain the node public keys corresponding to the G consensus nodes respectively, and to perform node signature verification on the node signature information in the node signature set based on the obtained G node public keys to obtain the node signature verification result; and to determine the second data verification result based on the node signature verification result.

[0246] In one implementation, the target verification information includes first time association information associated with the target transaction data; the first time association information includes the data timestamp of the target transaction data.

[0247] The timestamp verification subunit 2213 is used to obtain the timestamp to be verified of the target transaction data from the data location request, compare the timestamp to be verified with the data timestamp to obtain the timestamp verification result, and determine the second data verification result based on the timestamp verification result.

[0248] In one implementation, the target verification information includes second time-related information associated with the target contract data; the second time-related information includes the certificate validity period corresponding to the public key certificate of the consensus node in the core consensus network;

[0249] The certificate verification subunit 2214 is used to use the public key certificate of the consensus node synchronized from the blockchain as the first public key certificate; the first public key certificate contains the node public key used to verify the node signature set associated with the target block where the target transaction data is located; the usage duration of the first public key certificate is obtained, and the usage duration of the first public key certificate is compared with the certificate validity duration to obtain the certificate validity verification result; the second data verification result is determined based on the certificate validity verification result.

[0250] The specific implementation methods of the root verification subunit 2211, signature verification subunit 2212, timestamp verification subunit 2213, and certificate verification subunit 2214 can be found above. Figure 4 The description of step S202 in the corresponding embodiments will not be repeated here.

[0251] The proof return unit 222 is used to return the first verification proof information corresponding to the target business data to the business object based on the second data verification result.

[0252] The specific implementation methods of the authenticity verification unit 221 and the proof return unit 222 can be found in the above description. Figure 4 The description of step S202 in the corresponding embodiments will not be repeated here.

[0253] The target business data is determined by the consensus nodes in the core consensus network after they call the target business contract on the blockchain to execute the target transaction business; the target business data includes one or more of the target transaction data or target contract data associated with the target transaction business; the target transaction business is initiated by the second business node; the second business node belongs to the second type of business node in the business network;

[0254] The data synchronization module 23 is used to obtain the target data identifier and the target verification information of the target business data from the blockchain when the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, and to store the target data identifier and the target verification information.

[0255] The second business node stores the original data information of the target business data synchronized from the consensus node; the target verification information includes additional reading information; the additional reading information is determined by the consensus node calling the target business contract to register permissions for the original authorization information submitted by the second business node.

[0256] The original text verification module 24 is used to obtain the address of the business node that stores the original text information of the target business data when the authenticity verification includes original text verification of the target business data; based on the read additional information, it sends an original text verification request for the target business data to the second business node corresponding to the business node address; the original text verification request is used to instruct the second business node to perform original text verification of the target business data based on the original text information of the target business data, obtain a third data verification result, and return the second verification certificate information corresponding to the target business data to the business object based on the third data verification result.

[0257] The third forwarding module 25 is used to forward a data location request carrying the target data identifier to the consensus node in the core consensus network when no verification node storing the target verification information is found among the M verification nodes, so that the consensus node can verify the authenticity of the target business data.

[0258] The fourth forwarding module 26 is used to forward a data location request carrying the target data identifier to the fourth verification node if the node status of the second verification node is in a failed state or the target verification information stored by the second verification node is incomplete. The node mapping identifier of the fourth verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, except for the second node mapping identifier. The fourth verification node is used to back up the target verification information. The data location request is used to instruct the fourth verification node to perform authenticity verification on the target business data based on the backed-up target verification information.

[0259] Among them, the target business contract is used to determine the verifiable timestamp of the target business data;

[0260] The data clearing module 27 is used to obtain the verification time limit event generated by the consensus node based on the verifiable timestamp of the target business data. When the verifiable timestamp in the verification time limit event is obtained, if the data timestamp of the target business data is earlier than the verifiable timestamp, the target data identifier and target verification information are cleared.

[0261] The specific implementation methods of the request receiving module 21, authenticity verification module 22, data synchronization module 23, original text verification module 24, third forwarding module 25, fourth forwarding module 26, and data clearing module 27 can be found above. Figure 4 The descriptions of steps S201-S202 in the corresponding embodiments will not be repeated here. It should be understood that the descriptions of the beneficial effects obtained by using the same method will also not be repeated.

[0262] Please see Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 11As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 11 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0263] In such Figure 11 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the aforementioned... Figure 3 , Figure 4 The description of the data processing method based on the hierarchical chain network in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0264] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores the computer program executed by the data processing device 1 and the data processing device 2 based on the hierarchical chain network mentioned above. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 4 The description of the data processing method based on the hierarchical chain network in any corresponding embodiment is therefore not repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0265] The aforementioned computer-readable storage medium can be an internal storage unit of the data processing apparatus based on a hierarchical chain network provided in any of the foregoing embodiments, or an internal storage unit of the aforementioned computer device, such as a hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0266] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned... Figure 3 , Figure 4 The method is provided in any of the corresponding embodiments. Furthermore, the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0267] For further details, please see Figure 12 , Figure 12 This is a schematic diagram of the structure of a data processing system based on a hierarchical chain network provided in an embodiment of this application. Figure 12 As shown, the data processing system 3 based on a hierarchical chain network can include a data processing device 1a and a data processing device 2a. The data processing device 1a can be the aforementioned... Figure 9 The data processing device 1 based on the hierarchical chain network in the corresponding embodiment can be understood to be integrated into the above-mentioned... Figure 2 The verification node 20A in the corresponding embodiment will not be described again here. The data processing device 2a can be the one described above. Figure 10 The data processing device 2 based on the hierarchical chain network in the corresponding embodiment can be understood to be integrated into the above-mentioned... Figure 2The verification node 20B in the corresponding embodiment will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again. For technical details not disclosed in the embodiments of the data processing system based on hierarchical chain networks involved in this application, please refer to the description of the method embodiments of this application.

[0268] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0269] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0270] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on hierarchical chain networks, characterized in that, The layered blockchain network includes at least a verification network and a core consensus network; the verification network is deployed in the business network of the layered blockchain network, the business network is independent of the core consensus network, and the M verification nodes in the verification network are composed of the first type of business nodes in the business network; M is a positive integer; The method is executed by the first verification node among the M verification nodes, and the method includes: The system obtains a data location request for target business data sent by a business object through a first business node; the first business node belongs to a second type of business node in the business network; the second type of business node is a business node in the business network other than the first type of business node. When the target data identifier of the target business data is obtained from the data location request, the first node mapping identifier of the first inspection node is determined in the ring mapping space corresponding to the inspection network. In the addressing direction indicated by the ring mapping space, the target data identifier is verified by a resource location table associated with the first node address of the first node mapping identifier to obtain a first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction; When the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the synchronized data information on the chain, in the node routing list maintained by the first verification node, the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction is taken as the second node mapping identifier, and the data positioning request carrying the target data identifier is forwarded to the second verification node corresponding to the second node mapping identifier; when the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, the second verification node is used to verify the authenticity of the target business data.

2. The method according to claim 1, characterized in that, The target data identifier is obtained by mapping the target business data to the ring mapping space corresponding to the verification network; When obtaining the target data identifier of the target business data from the data location request, determining the first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network includes: When the target data identifier of the target business data is obtained from the data location request, the first node address of the first verification node is obtained; The first node address is mapped to the ring mapping space to obtain the first node mapping identifier of the first verification node.

3. The method according to claim 1, characterized in that, In the addressing direction indicated by the ring mapping space, the target data identifier is checked using a resource location table associated with the first node address of the first node mapping identifier to obtain a first data check result, including: In the addressing direction indicated by the ring mapping space, obtain the neighboring node mapping identifier contained in the resource location table associated with the first node address of the first node mapping identifier, and determine the target neighboring node mapping identifier in the neighboring node mapping identifier; Based on the first node mapping identifier and the target neighbor node mapping identifier, the target data identifier is verified to obtain the first data verification result.

4. The method according to claim 3, characterized in that, The synchronization data identifier of the on-chain synchronization data information includes the target synchronization data identifier of the target on-chain synchronization data information stored at the target neighbor node address corresponding to the target neighbor node mapping identifier. The step of performing data verification on the target data identifier based on the first node mapping identifier and the target neighbor node mapping identifier to obtain a first data verification result includes: If the target data identifier is located within the spatial range determined by the first node mapping identifier and the target neighboring node mapping identifier, then the target neighboring node mapping identifier is determined to be the node mapping identifier closest to the target data identifier in the addressing direction, and the target data identifier is determined to be included in the target synchronization data identifier; If the target data identifier is located outside the spatial range determined by the first node mapping identifier and the target neighboring node mapping identifier, then it is determined that the target data identifier is not included in the target synchronization data identifier. The data verification result when the target synchronization data identifier contains the target data identifier or when the target synchronization data identifier does not contain the target data identifier shall be used as the first data verification result.

5. The method according to claim 4, characterized in that, Also includes: When the first data verification result indicates that the target data identifier is included in the target synchronization data identifier, the data location request carrying the target data identifier is forwarded to the third verification node corresponding to the target neighbor node mapping identifier; the data location request is used to instruct the third verification node to verify the authenticity of the target business data.

6. The method according to claim 3, characterized in that, The number of neighbor node mapping identifiers is N; N is a positive integer greater than 1; Determining the target neighbor node mapping identifier from the neighbor node mapping identifier includes: Among the N neighboring node mapping identifiers, find the neighboring node mapping identifier corresponding to the first node address located after the first node address in the addressing direction, and use the found neighboring node mapping identifier as the first neighboring node mapping identifier. Obtain the node status of the first neighboring verification node corresponding to the first neighboring node mapping identifier. If the node status of the first neighboring verification node is valid, then use the first neighboring node mapping identifier as the target neighboring node mapping identifier. If the node status of the first neighboring verification node is invalid, then the target neighboring node mapping identifier is determined from (N-1) neighboring node mapping identifiers other than the first neighboring node mapping identifier.

7. The method according to claim 1, characterized in that, The node routing list contains K routing node mapping identifiers; K is a positive integer greater than 1 and less than or equal to the spatial size parameter of the ring mapping space; The step of selecting the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction from the node routing list maintained by the first verification node as the second node mapping identifier includes: Among the K routing node mapping identifiers, find the routing node mapping identifier that is furthest from the first node mapping identifier, and use the found routing node mapping identifier as the first routing node mapping identifier; If the first routing node mapping identifier is located within the spatial range determined by the first node mapping identifier and the target data identifier, then the first routing node mapping identifier is determined to be the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction, and the first routing node mapping identifier is used as the second node mapping identifier. If the first routing node mapping identifier is located outside the spatial range determined by the first node mapping identifier and the target data identifier, then the second node mapping identifier is determined from (K-1) routing node mapping identifiers other than the first routing node mapping identifier.

8. A data processing method based on hierarchical chain networks, characterized in that, The layered blockchain network includes at least a verification network and a core consensus network; the verification network is deployed in the business network of the layered blockchain network, the business network is independent of the core consensus network, and the M verification nodes in the verification network are composed of the first type of business nodes in the business network; M is a positive integer; The method is executed by the second verification node among the M verification nodes, and the method includes: Obtain the data location request carrying the target data identifier forwarded by the first verification node among the M verification nodes; The data location request is a request sent by a business object through a first business node for target business data corresponding to the target data identifier; the first business node belongs to the second type of business nodes in the business network; the second type of business nodes are business nodes in the business network other than the first type of business nodes; the first verification node is used to determine the first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network when it obtains the target data identifier of the target business data from the data location request, and is used to locate the target business data in the addressing direction indicated by the ring mapping space through a resource location table associated with the first node address of the first node mapping identifier. The data identifier is used to perform data verification to obtain a first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction; the second node mapping identifier of the second verification node refers to the node mapping identifier that is closest to the target data identifier in the node routing list maintained by the first verification node in the reverse direction of the addressing direction when the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the on-chain synchronization data information; When the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, the authenticity of the target business data is verified.

9. The method according to claim 8, characterized in that, The target business data is determined by the consensus nodes in the core consensus network after they call the target business contract on the blockchain to execute the target transaction business; the target business data includes one or more of the target transaction data or target contract data associated with the target transaction business; The target transaction was initiated by the second business node; The second service node belongs to the second type of service node in the service network; the method further includes: When the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, the target data identifier and the target business data target verification information are obtained from the blockchain, and the target data identifier and the target verification information are stored.

10. The method according to claim 9, characterized in that, When the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, verifying the authenticity of the target service data includes: When the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction, the target business data is verified for authenticity based on the target verification information to obtain the second data verification result; Based on the second data verification result, the first verification certificate information corresponding to the target business data is returned to the business object.

11. The method according to claim 10, characterized in that, The target verification information includes a Merkel path associated with the target transaction data; The step of verifying the authenticity of the target business data based on the target verification information to obtain a second data verification result includes: Obtain the transaction hash value of the target transaction data, and determine the root of the tree to be verified based on the transaction hash value of the target transaction data and the Merkel path; Obtain the Merkel root from the block header information of the target block where the target transaction data is located, compare the root to be verified with the Merkel root, and obtain the root verification result. The second data verification result is determined based on the root verification result.

12. The method according to claim 10, characterized in that, The target verification information includes a set of node signatures associated with the target block where the target transaction data is located; the set of node signatures includes node signature information obtained by each of the G consensus nodes in the core consensus network signing the target block; G is a positive integer; The step of verifying the authenticity of the target business data based on the target verification information to obtain a second data verification result includes: Obtain the public keys corresponding to the G consensus nodes respectively, and verify the node signature information in the node signature set based on the obtained G public keys to obtain the node signature verification result. The second data verification result is determined based on the node signature verification result.

13. The method according to claim 10, characterized in that, The second service node stores the original data information of the target service data synchronized from the consensus node; the target verification information includes additional reading information; the additional reading information is determined by the consensus node calling the target service contract to register permissions for the original authorization information submitted by the second service node; the method further includes: When the authenticity verification includes the original text verification of the target business data, the address of the business node that stores the original text information of the target business data is obtained; Based on the additional information read, a plaintext verification request for the target business data is sent to the second business node corresponding to the business node address; the plaintext verification request is used to instruct the second business node to perform plaintext verification on the target business data based on the plaintext information of the target business data, obtain a third data verification result, and return the second verification certificate information corresponding to the target business data to the business object based on the third data verification result.

14. The method according to claim 9, characterized in that, Also includes: If no verification node storing the target verification information is found among the M verification nodes, the data location request carrying the target data identifier is forwarded to the consensus node in the core consensus network so that the consensus node can verify the authenticity of the target business data.

15. The method according to claim 9, characterized in that, Also includes: If the node status of the second verification node is invalid or the target verification information stored by the second verification node is missing, the data location request carrying the target data identifier is forwarded to the fourth verification node; the node mapping identifier of the fourth verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, except for the second node mapping identifier. The fourth verification node is used to back up the target verification information; The data location request is used to instruct the fourth verification node to perform an authenticity verification on the target business data based on the backed-up target verification information.

16. The method according to claim 9, characterized in that, The target business contract is used to determine the verifiable timestamp of the target business data; the method further includes: The consensus node obtains the verification time limit event generated based on the verifiable timestamp of the target business data. When the verifiable timestamp in the verification time limit event is obtained, if the data timestamp of the target business data is earlier than the verifiable timestamp, the target data identifier and the target verification information are cleared.

17. A data processing device based on a hierarchical chain network, characterized in that, The layered blockchain network includes at least a verification network and a core consensus network; the verification network is deployed in the business network of the layered blockchain network, the business network is independent of the core consensus network, and the M verification nodes in the verification network are composed of the first type of business nodes in the business network; M is a positive integer; The device operates in the first inspection node among the M inspection nodes, and the device includes: The request acquisition module is used to acquire a data location request for target business data sent by a business object through a first business node; the first business node belongs to a second type of business node in the business network; the second type of business node is a business node in the business network other than the first type of business node. The identifier determination module is used to determine the first node mapping identifier of the first inspection node in the ring mapping space corresponding to the inspection network when the target data identifier of the target business data is obtained from the data location request. The identifier verification module is used to perform data verification on the target data identifier in the addressing direction indicated by the ring mapping space through a resource location table associated with the first node address of the first node mapping identifier, and obtain a first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction; The first forwarding module is configured to, when the first data verification result indicates that the target data identifier is not included in the synchronization data identifier of the synchronized data information on the chain, select the node mapping identifier that is closest to the target data identifier in the reverse direction of the addressing direction from the node routing list maintained by the first verification node as the second node mapping identifier, and forward the data positioning request carrying the target data identifier to the second verification node corresponding to the second node mapping identifier; when the second node mapping identifier of the second verification node is the node mapping identifier that is closest to the target data identifier in the addressing direction, the second verification node is used to verify the authenticity of the target service data.

18. A data processing device based on a hierarchical chain network, characterized in that, The layered blockchain network includes at least a verification network and a core consensus network; the verification network is deployed in the business network of the layered blockchain network, the business network is independent of the core consensus network, and the M verification nodes in the verification network are composed of the first type of business nodes in the business network; M is a positive integer; The device operates in the second inspection node among the M inspection nodes, and the device includes: The request receiving module is configured to acquire a data location request carrying a target data identifier forwarded by a first verification node among the M verification nodes; the data location request is a request sent by a service object through the first service node for target service data corresponding to the target data identifier; the first service node belongs to the second type of service nodes in the service network; the second type of service nodes are service nodes in the service network other than the first type of service nodes; the first verification node is configured to determine a first node mapping identifier of the first verification node in the ring mapping space corresponding to the verification network when it acquires the target data identifier of the target service data from the data location request, and is configured to, in the addressing direction indicated by the ring mapping space, communicate with the first node... The resource location table associated with the first node address of the mapping identifier performs data verification on the target data identifier to obtain a first data verification result; the neighboring node address corresponding to the neighboring node mapping identifier in the resource location table is used to store the synchronization data identifier of the on-chain synchronization data information synchronized from the blockchain corresponding to the core consensus network; the neighboring node address is the node address located after the first node address in the addressing direction; the second node mapping identifier of the second verification node refers to the node mapping identifier that is closest to the target data identifier in the node routing list maintained by the first verification node in the reverse direction of the addressing direction when the first data verification result indicates that the synchronization data identifier of the on-chain synchronization data information does not contain the target data identifier; The authenticity verification module is used to verify the authenticity of the target business data when the second node mapping identifier of the second verification node is the node mapping identifier closest to the target data identifier in the addressing direction.

19. A computer device, characterized in that, include: Processor and memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to invoke the computer program to cause the computer device to perform the method according to any one of claims 1-16.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-16.

Images