Blockchain network-based business data processing method and device, and related equipment

Abstract

A business data processing method and device based on a blockchain network and related equipment can be applied to various fields or scenarios such as cloud technology, artificial intelligence, blockchain, Internet of Vehicles, intelligent transportation, smart home, etc. The method comprises: in response to the business data of a target business corresponding to a business block meeting approval conditions, generating a synchronous approval event of the target business; broadcasting the synchronous approval event on a subchain, the synchronous approval event being used to trigger a relay node of the subchain to generate first cross-chain data according to event information of the synchronous approval event and send the first cross-chain data to a main chain; receiving second cross-chain data sent by a relay node of the main chain, and broadcasting the second cross-chain data in the subchain, the second cross-chain data being used to trigger a subchain node of the subchain to complete business processing of the target business, and the second cross-chain data being generated by the relay node of the main chain according to an approval event block of approval information of the synchronous approval event. The application can realize data processing of an approved business based on a blockchain network.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a business data processing method, apparatus and related equipment based on a blockchain network. Background Technology

[0002] In business management, it is often necessary to review and approve initiated business transactions. Business approval involves collaboration between multiple departments, and some approval processes require strict adherence to procedures. Therefore, deploying secure networks is often used to handle approval processes and assist in completing approval tasks.

[0003] Currently, the approval process conducted through relevant networks may be susceptible to problems such as data corruption leading to errors in the approval process. For example, data may be tampered with by unauthorized entities during the interaction process, resulting in errors in the approval process. Summary of the Invention

[0004] This application provides a business data processing method, apparatus, and related equipment based on a blockchain network, which can realize data processing for approval business based on a blockchain network.

[0005] On one hand, embodiments of this application provide a business data processing method based on a blockchain network. The blockchain network includes a main chain and at least one sub-chain. The main chain includes multiple main chain nodes, and the sub-chain includes multiple sub-chain nodes. The main chain nodes communicate with one or more sub-chain nodes of the sub-chain through relay nodes of the main chain. The sub-chain nodes communicate with one or more main chain nodes of the main chain through relay nodes of the sub-chain. The method includes:

[0006] In response to the business data of the target business corresponding to the business block meeting the approval conditions, a synchronous approval event for the target business is generated;

[0007] The synchronous approval event is broadcast on the sub-chain. The synchronous approval event is used to trigger the relay node of the sub-chain to generate first cross-chain data based on the event information of the synchronous approval event and send it to the main chain. The first cross-chain data is used to instruct the main chain node of the main chain to respond to the first cross-chain data to generate an approval event block of the approval information of the synchronous approval event.

[0008] The system receives second cross-chain data sent by the relay node of the main chain and broadcasts the second cross-chain data in the sub-chain. The second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business. The second cross-chain data is generated by the relay node of the main chain based on the approval event block.

[0009] On one hand, embodiments of this application provide a business data processing method based on a blockchain network. The blockchain network includes a main chain and at least one sub-chain. The main chain includes multiple main chain nodes, and the sub-chain includes multiple sub-chain nodes. The main chain nodes communicate with one or more sub-chain nodes of the sub-chain through relay nodes of the main chain. The sub-chain nodes communicate with one or more main chain nodes of the main chain through relay nodes of the sub-chain. The method includes:

[0010] The relay node of the sub-chain receives the first cross-chain data sent by the relay node of the sub-chain. The first cross-chain data is generated by the relay node of the sub-chain triggered by the synchronous approval event of the target business. The synchronous approval event is generated by the sub-chain node of the sub-chain in response to the business data of the target business corresponding to the business block meeting the approval conditions.

[0011] In response to the first cross-chain data, an approval event block is generated to provide approval information for the synchronous approval event. The approval event block is used to trigger the relay node of the main chain to generate second cross-chain data based on the approval event block and send it to the sub-chain. The second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business.

[0012] On one hand, embodiments of this application provide a business data processing device based on a blockchain network. The blockchain network includes a main chain and at least one sub-chain. The main chain includes multiple main chain nodes, and the sub-chain includes multiple sub-chain nodes. The main chain nodes communicate with one or more sub-chain nodes through relay nodes of the main chain, and the sub-chain nodes communicate with one or more main chain nodes of the main chain through relay nodes of the sub-chain. The device includes:

[0013] The processing unit is used to generate a synchronous approval event for the target business in response to the business data of the target business corresponding to the business block meeting the approval conditions.

[0014] A processing unit is configured to broadcast the synchronous approval event on the sub-chain, wherein the synchronous approval event is configured to trigger the relay node of the sub-chain to generate first cross-chain data based on the event information of the synchronous approval event and send it to the main chain; the first cross-chain data is configured to instruct the main chain node of the main chain to respond to the first cross-chain data to generate an approval event block containing the approval information of the synchronous approval event;

[0015] A receiving unit is used to receive the second cross-chain data sent by the relay node of the main chain;

[0016] The processing unit is further configured to broadcast the second cross-chain data in the sub-chain, the second cross-chain data being used to trigger the sub-chain nodes of the sub-chain to complete the business processing of the target business, the second cross-chain data being generated by the relay node of the main chain based on the approval event block.

[0017] On one hand, embodiments of this application provide a business data processing device based on a blockchain network. The blockchain network includes a main chain and at least one sub-chain. The main chain includes multiple main chain nodes, and the sub-chain includes multiple sub-chain nodes. The main chain nodes communicate with one or more sub-chain nodes through relay nodes of the main chain, and the sub-chain nodes communicate with one or more main chain nodes of the main chain through relay nodes of the sub-chain. The device includes:

[0018] The receiving unit is used to receive the first cross-chain data sent by the relay node of the sub-chain. The first cross-chain data is generated by the relay node of the sub-chain triggered by the synchronous approval event of the target business. The synchronous approval event is generated by the sub-chain node of the sub-chain in response to the business data of the target business corresponding to the business block meeting the approval conditions.

[0019] The processing unit is configured to respond to the first cross-chain data and generate an approval event block of the approval information of the synchronous approval event; the approval event block is configured to trigger the relay node of the main chain to generate second cross-chain data based on the approval event block and send it to the sub-chain; the second cross-chain data is configured to trigger the sub-chain node of the sub-chain to complete the business processing of the target business.

[0020] On one hand, embodiments of this application provide a computer device, which includes a processor, a communication interface, and a memory. The processor, the communication interface, and the memory are interconnected. The memory stores a computer program, and the processor is used to call the computer program to execute any of the above-described possible implementations of the blockchain network-based business data processing method.

[0021] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements a business data processing method based on a blockchain network in any possible implementation manner.

[0022] On the one hand, embodiments of this application also provide a computer program product, which includes a computer program or computer instructions, and the computer program or computer instructions are executed by a processor to implement the steps of the business data processing method based on a blockchain network provided in embodiments of this application.

[0023] On the one hand, embodiments of this application also provide a computer program, the computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium, the processor of a computer device reading the computer instructions from the computer-readable storage medium, the processor executing the computer instructions, causing the computer device to execute the business data processing method based on a blockchain network provided in embodiments of this application.

[0024] The business data processing method proposed in this application can be implemented based on a blockchain network. Through the defined interaction process between the main chain and the sub-chain, the data processing of approval business can be realized based on the blockchain network. This allows the business logic of the sub-chain to be managed by the main chain during the business approval process, ensuring the security of cross-chain business processing and greatly reducing the possibility of business approval-related data being illegally tampered with or destroyed. Attached Figure Description

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

[0026] Figure 1 A schematic diagram of a blockchain network architecture provided for an embodiment of this application;

[0027] Figure 2a A schematic diagram of a two-layer network architecture provided in this application;

[0028] Figure 2b A schematic diagram of a blockchain network architecture provided for an embodiment of this application;

[0029] Figure 2c A schematic diagram illustrating the architecture of applying a two-layer network to an electronic invoice business scenario, as provided in this application;

[0030] Figure 3 A flowchart illustrating a business data processing method based on a blockchain network, provided as an embodiment of this application;

[0031] Figure 4 A flowchart illustrating another business data processing method based on a blockchain network provided in this application embodiment;

[0032] Figure 5 A flowchart illustrating another business data processing method based on a blockchain network provided in this application embodiment;

[0033] Figure 6 This application provides a schematic diagram of the structure of a service block.

[0034] Figure 7 A flowchart illustrating another blockchain-based business data processing method provided in this application embodiment;

[0035] Figure 8 A schematic diagram of the structure of a business data processing device based on a blockchain network provided in this application embodiment;

[0036] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0037] The technical methods in 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 in 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.

[0038] See Figure 1 The blockchain network 100 shown refers to a system for data sharing between nodes, which may include multiple nodes 101 (e.g., ...). Figure 1 In this context, nodes 101 (such as Node 1, Node 2, etc.) can refer to various clients within the blockchain network. Each node 101, in its normal operation, receives input information and maintains the shared data within the blockchain network based on this received input information.

[0039] Regarding the aforementioned blockchain network 100, when used in certain scenarios within commercial organizations, such as electronic invoices, not all nodes in the blockchain network have sufficient resources and the necessity to become nodes executing blockchain consensus. To adapt to business needs (such as separation of internal and external networks, business networks, and office networks) and to improve data security and confidentiality, this application's embodiments primarily focus on implementing corresponding approval processes for a two-layer network of "witness network-consensus network."

[0040] See Figure 2a The two-layer network proposed in this application includes a witness network 200 and a consensus network 201. Business nodes are deployed in the witness network 200, while consensus nodes running the blockchain consensus protocol are deployed in the consensus network 201. The two interact through a routing boundary.

[0041] Consensus network 201 includes a main consensus network 202 and at least one sub-consensus network 203 (e.g., ...). Figure 2aThe examples in the text include consensus sub-networks 1, 2, and 3. The main consensus network 202 has a main blockchain, which includes multiple main chain nodes; that is, each consensus node in the main consensus network 202 is a main chain node. This main chain can manage the sub-chains uniformly. The blockchain in the consensus sub-network 203 is a sub-chain, which includes multiple sub-chain nodes; that is, each consensus node in the consensus sub-network 203 is a sub-chain node. One consensus sub-network 203 corresponds to one sub-chain.

[0042] In one embodiment, the witness network 200 may also include multiple witness sub-networks, each capable of handling different services. For example, witness sub-network 1 might respond to a service request from a first province, while witness sub-network 2 might respond to a service request from a second province. Therefore, as... Figure 2b As shown, a witness subnetwork can correspond to a consensus subnetwork. The witness subnetwork can obtain block header data and partially authorized visible block data from the corresponding consensus subnetwork. Simultaneously, when the witness subnetwork receives a business request, it can send the relevant business data to the corresponding consensus subnetwork to complete the storage consensus of the business data on the subchain within the corresponding consensus subnetwork.

[0043] See Figure 2c , Figure 2c This application provides an architectural diagram illustrating the application of a two-layer network in an electronic invoice business scenario. The business layer, routing proxy layer, and core consensus network layer constitute the complete blockchain business system. The business layer resides within the witness network 200 and includes at least one business node. This business node can handle tax (local tax bureau), invoice (corporate invoicing), and payment-related transactions. For example… Figure 2c The business nodes shown can include terminal devices corresponding to the electronic tax bureau, terminal devices corresponding to enterprises, and terminal devices corresponding to consumers.

[0044] The core consensus network layer is located within consensus network 201. Consensus nodes can be trusted (computation) nodes, each running a permissioned contract and storing blocks from the blockchain. Additionally, the core consensus network layer includes one or more core chains, such as core chain 1 and core chain 2 in the tax network. Each core chain includes sub-chains and a main chain.

[0045] The business layer can submit business operation interactions to the core consensus network layer through the routing proxy layer. The routing proxy layer plays a role in isolating the business layer and the core consensus network layer. The proxy layer includes at least one proxy node, which can provide routing services, authentication services, certificate caching services, peer-to-peer (P2P) services, etc.

[0046] Figure 2cThe core consensus network layer in the protocol can include a main chain and sub-chains. The main chain and sub-chains communicate through relay nodes, which can be one or more. The main chain's main chain nodes communicate with one or more sub-chain nodes through the main chain's relay nodes, and the sub-chain nodes communicate with one or more main chain nodes through the sub-chain's relay nodes. In one embodiment, the main chain's relay node can be a specific main chain node or a dedicated node independent of the main chain; similarly, the sub-chain's relay node can be a specific sub-chain node or a dedicated node independent of the sub-chain.

[0047] In the business data processing method provided in this application, when a consensus node (i.e., a sub-chain node of a sub-chain) in the consensus sub-network 203 receives an approval business that requires approval, it can generate a synchronous approval event for the approval business. By broadcasting the synchronous approval event on the sub-chain, the relay node of the sub-chain can be triggered to generate first cross-chain data based on the event information of the synchronous approval event and send it to the consensus main network 202. The consensus node (i.e., the main chain node of the main chain) in the consensus main network 202 can respond to the first cross-chain data to approve the synchronous approval event, thereby generating an approval event block containing the approval information of the synchronous approval event, and broadcasting an approval completion event in the main chain. By broadcasting the approval completion event, the relay node of the main chain can be triggered to generate second cross-chain data based on the approval event block and send it to the consensus sub-network 203. The consensus node in the consensus sub-network 203 can receive the second cross-chain data sent by the relay node of the main chain. By broadcasting the second cross-chain data in the sub-chain, the consensus node in the consensus sub-network 203 can be triggered to complete the business processing of the approval business.

[0048] Any node in a blockchain network (or a two-layer network) (including consensus nodes, business nodes, relay nodes, sub-chain nodes, and main-chain nodes) can be a computer device or a computer program. The computer device includes terminal devices and servers; terminal devices can include smartphones, tablets, smart wearable devices, smart voice interaction devices, smart home appliances, personal computers, in-vehicle terminals, etc., without limitation. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0049] The specific implementation of the business data processing method based on a blockchain network provided in this application embodiment is described in detail below. (See also...) Figure 3 , Figure 3 This is a flowchart illustrating a business data processing method based on a blockchain network, provided as an embodiment of this application. The method is applied to sub-chain nodes of a sub-chain (such as those described above). Figure 2a The method includes: (consensus nodes in the consensus subnetwork 203 shown)

[0050] S301. In response to the business data of the target business corresponding to the business block meeting the approval conditions, a synchronous approval event for the target business is generated.

[0051] A consensus subnetwork can correspond to the processing of a specific business. For example, based on business type, consensus subnetwork 1 can be used for storing consensus on invoice transactions, while consensus subnetwork 2 can be used for storing consensus on payment transactions. Alternatively, based on province, consensus subnetwork 1 can be used for storing consensus on invoice transactions in the first province, while consensus subnetwork 2 can be used for storing consensus on invoice transactions in the second province. Therefore, business nodes in the witness network can forward the business data of the target business to the consensus subnetwork processing the target business through proxy nodes, thereby enabling the subchain nodes of the corresponding subchain of the consensus subnetwork to obtain the business data of the target business. The business data of the target business is any data that needs to be uploaded to the chain under the business that the subchain node can process. The subchain node can package the business data of the target business into a block, called a business block, which is the block waiting to be consensus-uploaded to the chain in the subchain. The subchain node that packages the business block can broadcast the business block in the subchain to other subchain nodes in the consensus subnetwork for consensus. When a majority of the subchain nodes in the consensus subnetwork (e.g., 2 / 3) reach a consensus on the business block, the business block is stored on the subchain, thereby realizing the consensus on the business block on the chain.

[0052] When a sub-chain node packages the business data of a target business into a business block, it executes the target business, including: determining whether the business data of the target business meets the approval conditions; if the business data of the target business does not meet the approval conditions, it means that the target business can be executed without the main chain's approval and confirmation, and the sub-chain node can directly execute the target business, obtain the business execution result of the target business, and package the business data and business execution result of the target business into the business block together; if the business data of the target business meets the approval conditions, it means that the target business needs the main chain's approval and confirmation before it can continue to be executed, and the sub-chain node can generate a synchronous approval event for the target business in response to the business data of the target business corresponding to the business block meeting the approval conditions.

[0053] The target business's business data includes data that enables the target business function. For example, if the target business is a tax refund, the business data could include information such as tax refund review materials, the approver, and the applicant. In one implementation, the process of determining whether the approval conditions are met can be determined using the data that enables the target business function. For instance, if the business data includes both the approver and the applicant, it can be determined that the target business meets the approval conditions. The target business's business data can also include a business identifier representing the business type. In another implementation, the sub-chain node can determine whether the business identifier carried in the target business's business data belongs to a preset identifier list. If it does, the target business's business data meets the approval conditions. The preset identifier list includes business identifiers for business types that require approval.

[0054] S302. Broadcast a synchronous approval event on the subchain. The synchronous approval event is used to trigger the relay node of the subchain to generate the first cross-chain data based on the event information of the synchronous approval event and send it to the main chain. The first cross-chain data is used to instruct the main chain node of the main chain to respond to the first cross-chain data and generate an approval event block with approval information of the synchronous approval event.

[0055] A relay node can be a computer device or computer program capable of providing relay services. In one embodiment, for any node in the blockchain network, an RBC (Radio Bearer Control) interface can be configured between that node and a sub-chain node of the sub-chain. This node then acts as a relay node for the sub-chain and can communicate with the sub-chain node. Similarly, an RBC interface can be configured between any node and a main chain node of the main chain. This node then acts as a relay node for the main chain and can communicate with the main chain node. The number of relay nodes in the sub-chain and the main chain can be multiple.

[0056] Subchain nodes can broadcast synchronous approval events within their subchains. Broadcasting these events informs relay nodes on the subchain that the target business requires approval from the main chain. Upon receiving a synchronous approval event, a relay node on the subchain can retrieve its event information. This information may include a notification message indicating that the target business requires approval, as well as the necessary data. For example, if the target business is a tax refund, the event information might include approval from department head A and the applicant's tax refund application materials. Further, based on this information, the relay node generates first cross-chain data and sends it to the main chain. Since this first cross-chain data includes the data required for the target business approval, the main chain node can respond to it, completing the approval process and generating an approval event block containing the approval information. This approval information may include the approval result (approved or rejected), the completion time, and any notes. Notes can explain the approval result, such as an error in the applicant's identity information if the target business was rejected.

[0057] In one embodiment, the main chain node can package the event information and approval information of the synchronous approval event into the approval event block, and then upload the approval event block to the main chain for consensus, thereby ensuring that the event information of the synchronous approval event is stored on both the sub-chain and the main chain, and realizing the state synchronization between the sub-chain and the main chain.

[0058] S303. Receive the second cross-chain data sent by the relay node of the main chain and broadcast the second cross-chain data in the sub-chain. The second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business. The second cross-chain data is generated by the relay node of the main chain according to the approval event block.

[0059] After generating an approval event block containing approval information for a synchronous approval event, the main chain node can broadcast an approval completion event within the main chain. This broadcast informs the relay nodes of the target business that the approval process has been completed. At this point, the relay nodes can retrieve the approval event block from the main chain, generate second cross-chain data based on the approval information from the synchronous approval event included in the block, and send this second cross-chain data to the child chain. The child chain nodes can then broadcast the second cross-chain data sent by the relay nodes within their own child chain to inform all child chain nodes that the target business has been approved. This allows them to complete the business processing of the target business based on the approval result from the synchronous approval event. For example, if the synchronous approval event result is "approved," the child chain node can continue processing the target business; for instance, if the target business is a tax refund, the child chain node will execute the tax refund operation. If the synchronous approval event result is "disapproved," the child chain can terminate the business processing of the target business.

[0060] By employing the method described in this application, when a subchain business requires approval from the main chain, a synchronous approval event can be generated using the blockchain's event mechanism. This synchronous approval event enables the main chain and subchain, which were originally executing asynchronously, to interact, thereby realizing data processing for approval business based on the blockchain network and improving the transparency of the business processing process. At the same time, during the business approval process, the business logic of the subchain can be managed by the main chain, ensuring the security of cross-chain business processing and greatly reducing the possibility of the relevant data for business approval being illegally tampered with or destroyed.

[0061] See Figure 4 , Figure 4 This is a flowchart illustrating another business data processing method based on a blockchain network provided in an embodiment of this application. The method is applied to the main chain node of the main chain (e.g., the one described above). Figure 2a The method includes: (consensus nodes in the consensus main network 202 shown).

[0062] S401. Receive the first cross-chain data sent by the relay node of the sub-chain. The first cross-chain data is generated by the relay node of the sub-chain triggered by the synchronous approval event of the target business. The synchronous approval event is generated by the sub-chain node of the sub-chain in response to the business data of the target business corresponding to the business block meeting the approval conditions.

[0063] When a subchain node packages the business data of a target business into a business block, it determines whether the business data meets the approval conditions. If the subchain node determines that the business data meets the approval conditions, it generates a synchronous approval event for the target business. By broadcasting this synchronous approval event within the subchain, the subchain node can trigger the relay node of the subchain to generate the first cross-chain data using the event information. This first cross-chain data can then be sent to the mainchain node of the main chain.

[0064] S402. In response to the first cross-chain data, generate an approval event block containing the approval information of the synchronous approval event; the approval event block is used to trigger the main chain relay node to generate the second cross-chain data based on the approval event block and send it to the sub-chain; the second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business.

[0065] The first cross-chain data includes event information for synchronous approval events. This event information can include notification messages indicating that the target business requires approval, as well as the data needed for the approval process. Therefore, the main chain node can use the first cross-chain data to process synchronous approval events and generate an approval event block containing the approval information. This approval information can include the approval result (approval or rejection), the completion time, and remarks, such as the reason for the rejection of the business approval. Furthermore, the main chain node can broadcast an approval completion event on the main chain. Broadcasting this event informs the main chain relay nodes that the target business has been approved. At this point, the main chain relay nodes can retrieve the approval event block from the main chain, generate second cross-chain data based on the approval information of the synchronous approval events included in the block, and send the second cross-chain data to the child chain. Subchain nodes can broadcast the second cross-chain data sent by the main chain's relay nodes within the subchain to inform other subchain nodes that the target business has been approved. This allows them to process the target business based on the approval result in the synchronous approval event. For example, if the synchronous approval event results in approval, the subchain node can continue processing the target business (e.g., a tax refund). If the synchronous approval event results in disapproval, the subchain can terminate the processing of the target business.

[0066] By employing the method described in this application, when a subchain business requires approval from the main chain, a synchronous approval event can be generated using the blockchain's event mechanism. This synchronous approval event enables the main chain and subchain, which were originally executing asynchronously, to interact, thereby realizing data processing for approval business based on the blockchain network and improving the transparency of the business processing process. At the same time, during the business approval process, the business logic of the subchain can be managed by the main chain, ensuring the security of cross-chain business processing and greatly reducing the possibility of the relevant data for business approval being illegally tampered with or destroyed.

[0067] See Figure 5 , Figure 5 This is a flowchart illustrating another business data processing method based on a blockchain network provided in an embodiment of this application. The method is applied to the main chain nodes of the main chain and the sub-chain nodes of the sub-chains (e.g., as described above). Figure 2a (As shown in the consensus main network 202 and the consensus subnetwork 203), the method includes:

[0068] S501. When the subchain node of the subchain responds to the business data of the target business corresponding to the business block meeting the approval conditions, it generates a synchronous approval event for the target business.

[0069] In one embodiment, a service node in the witness network can send the service data of the target service to a proxy node, allowing the proxy node to verify the service node's permissions. This permission verification may include verifying whether the service node's node identifier belongs to a preset node list and whether the format of the target service's service data is correct. The preset node list may include node identifiers of malicious nodes, etc. When the permission verification is successful (e.g., the service node's node identifier does not belong to the preset node list and the target service's service data is in the correct format), the proxy node can determine the consensus sub-network for processing the target service based on its service type and send the target service's service data to the corresponding consensus sub-network. This allows sub-chain nodes of the corresponding sub-chain in that consensus sub-network to store the target service's service data in their own memory pools for subsequent packaging and processing into service blocks. Conversely, when the permission verification fails (e.g., the service node's node identifier belongs to the preset node list and / or the target service's service data is in the wrong format), the proxy node does not need to broadcast the target service's service data to any consensus sub-network; it can directly delete the target service's service data.

[0070] Specifically, the proxy node can encrypt the target business's data using a hash algorithm to obtain a first digest. It then signs the first digest using its private key to obtain a first signature, and sends the first signature and the target business's data to the sub-chain nodes. Further, the sub-chain node can obtain the proxy node's public key, decrypt the first signature to obtain first decrypted data, and encrypt the target business's data using the same hash algorithm to obtain first encrypted data. When the first decrypted data and the first encrypted data match, the signature verification is successful. Only then does the sub-chain node obtain the target business's data and store it in its own memory pool. This method prevents illegal data from being written to the sub-chain, improving the reliability of the sub-chain data.

[0071] Among them, illegal data can refer to data written by malicious nodes. The business processing of malicious nodes is inconsistent with the business processing of normal nodes. For example, malicious nodes can tamper with business data and business execution results.

[0072] The sub-chain node's memory pool stores multiple transaction data forwarded by the proxy node. The sub-chain node can retrieve a transaction set from the memory pool for packaging and processing. This transaction set includes one or more transaction data points, one of which is the business data of the target service. Furthermore, the sub-chain node can perform a hash transformation on each transaction data point in the transaction set to obtain the corresponding hash value. For example... Figure 6 As shown, the transaction set includes transaction data 1, transaction data 2, transaction data 3, and the target business data. The hash value of transaction data 1 is hash value 1, the hash value of transaction data 2 is hash value 2, the hash value of transaction data 3 is hash value 3, and the hash value of the target business data is hash value 4. Further, the sub-chain node can determine the Merkle root value of the packaged business block based on hash values ​​1, 2, 3, and 4. Specifically, hash values ​​1 and 2 are concatenated and hashed to obtain hash value 12; hash values ​​3 and 4 are concatenated and hashed to obtain hash value 34; and hash values ​​12 and 34 are concatenated and hashed to obtain hash value 1234. This hash value 1234 is the Merkle root value of the business block. After packaging the business block, it can be broadcast in the sub-chain, thereby achieving consensus and uploading the target business data to the sub-chain, ensuring the security, immutability, and traceability of the target business data.

[0073] in, Figure 6The business block shown includes a block header and a block body. The block header stores the input information feature values ​​of the current block (such as Merkle root value), the parent block feature values ​​(i.e., the block header feature values ​​of the parent block), the version number, the timestamp, and the difficulty value. The block body stores the input information.

[0074] In one embodiment, when a business block packages the business data of a target business, it generates a synchronous approval event and a notification message for the target business in response to the business data of the target business corresponding to the business block meeting the approval conditions. This notification message indicates that the approval status of the target business is pending approval. The sub-chain node sends this synchronous approval event notification message to the business requesting end of the target business. The business requesting end is the computer device that initiated the target business. The business requesting end can display the synchronous approval event notification message to inform the object that initiated the target business that the approval status of the target business is pending approval.

[0075] S502. Subchain nodes broadcast a synchronization approval event on the subchain. The synchronization approval event is used to trigger the relay nodes of the subchain to generate the first cross-chain data based on the event information of the synchronization approval event and send it to the main chain.

[0076] In one embodiment, subchain nodes can also generate a synchronization event block for the synchronized approval event, which includes the event information of the synchronized approval event. The synchronized approval event of the target business and its synchronization event block are further broadcast in the subchain. Broadcasting the synchronized approval event informs the relay nodes of the subchain that the target business requires mainchain approval; broadcasting the synchronization event block allows the event information of the synchronized approval event to be consensus-driven and uploaded to the chain within the subchain, ensuring the security, immutability, and traceability of the event information. Additionally, subchain nodes can package the event information of the synchronized approval event and the business data of the target business together into a business block, which then becomes the synchronized event block.

[0077] In one embodiment, the first cross-chain data includes: event information of the synchronous approval event (which can be obtained from the synchronous event block), first transaction data about the target business, and first verification data about the target business determined by the business block.

[0078] The event information for synchronous approval events may include notification messages that the target business requires approval, the business type of the target business, the application time of the target business, and identification information used to uniquely identify the applicant and the approver.

[0079] The first transaction data for a target business is generated based on the business data of the target business. This first transaction data refers to the data packaged into a business block. Besides the data required for the target business approval process, the business data may also include the contract address of the smart contract processing the target business, and unique identifiers for the approver and applicant.

[0080] The first verification data regarding the target business, determined through the business block, includes: the Merkle tree root value of the business block and the verification path of the first transaction data. This verification path is obtained based on the Merkle tree in the business block. Specifically, it involves identifying the leaf node corresponding to the first transaction data in the Merkle tree, and then sequentially searching upwards from the leaf node to find its parent node, thus determining multiple path nodes traversed from the leaf node to the root node. Nodes sharing a common parent node with these path nodes are designated as branch nodes, and these branch nodes constitute the verification path for the second transaction data. For example, Figure 6 The business data of the target business in the Merkle tree shown is the first transaction data. The verification path of the first transaction data includes: hash value 3 to hash value 12.

[0081] In a feasible implementation, the relay node of the sub-chain can send the first cross-chain data and the second signature data to the main chain. The second signature data can be obtained by the relay node of the sub-chain signing the second digest data using its private key. The second digest data is obtained by encrypting the first cross-chain data using a hash algorithm. The main chain node of the main chain can decrypt the second signature data using the public key of the relay node of the sub-chain to obtain the second decrypted data. It then uses the hash algorithm to encrypt the first cross-chain data to obtain the second encrypted data. When the second decrypted data and the second encrypted data match, the signature verification is considered successful. Only after the signature verification is successful can the main chain node obtain the first cross-chain data and execute the subsequent verification process of the first transaction data. This can prevent illegal data from being written to the main chain and improve the reliability of the main chain data.

[0082] S503, The main chain node receives the first cross-chain data sent by the relay node of the sub-chain.

[0083] The main chain node can receive the first cross-chain data sent by the relay node of the sub-chain, and verify the first transaction data in the first cross-chain data based on the first verification data in the first cross-chain data. Only after the first transaction data is verified successfully will the execution of S504 be triggered.

[0084] In one embodiment, the process of verifying the first transaction data based on the first verification data includes: obtaining a verification root value based on the first transaction data and the verification path included in the first verification data. For example... Figure 6The verification path for the first transaction data shown includes hash value 3 to hash value 12. After obtaining the first transaction data in the first cross-chain data, the main chain node can perform a hash transformation on the first transaction data to obtain hash value 4′. By concatenating hash value 4′ and hash value 3 and performing a hash transformation, hash value 34′ is obtained. By concatenating hash value 34′ and hash value 12 and performing a hash transformation, hash value 1234′ is obtained. This hash value 1234′ is the verification root value obtained based on the verification path included in the first transaction data and the first verification data. If the obtained verification root value is consistent with the Merkle tree root value included in the first verification data, for example, hash value 1234′ is consistent with hash value 1234, it indicates that the first transaction data in the first cross-chain data is tamper-proof. The main chain node can determine that the verification of the first transaction data has passed and execute S504 to generate an approval event block for the approval information of the synchronous approval event. If the obtained verification root value is inconsistent with the Merkle tree root value included in the first verification data (e.g., hash value 1234' is inconsistent with hash value 1234), it indicates that the first transaction data in the first cross-chain data has been tampered with, and the main chain node can stop processing the first cross-chain data. In this embodiment, by verifying the first cross-chain data sent by the relay node of the sub-chain, the main chain node can prevent the relay node of the sub-chain from submitting tampered data, thus ensuring the reliability of the main chain data and the security of the sub-chain business processing.

[0085] It should be noted that when the verification root value obtained from the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data, it can also indicate that the first cross-chain data consensus has been passed. Therefore, in one embodiment, the first cross-chain data can be broadcast in the main chain. If a majority of main chain nodes (e.g., 2 / 3) agree on the first cross-chain data, the first cross-chain data is written into the main chain, thereby completing the synchronous approval event of the sub-chain and the on-chain confirmation of the sub-chain business status in the main chain.

[0086] S504. The main chain node responds to the first cross-chain data and generates an approval event block containing the approval information of the synchronous approval event. The approval event block is used to trigger the main chain relay node to generate the second cross-chain data based on the approval event block and send it to the child chain.

[0087] In one embodiment, the main chain node can respond to the first cross-chain data to determine whether the target business is subject to manual or automatic approval. If the target business requires manual approval, the main chain node can identify the approval authority for the target business through the identifier information of the approver carried in the business data of the target business, and send an approval notification message to the approval authority. This approval notification message includes the first transaction data and the event information of the synchronous approval event included in the first cross-chain data. The approval authority can generate a business approval page based on the event information of the synchronous approval event and / or the first transaction data. Specifically, it can use the data required for the approval of the target business in the first transaction data (such as tax refund application materials) and the application time, business type, applicant, and approver of the target business in the event information of the synchronous approval event to generate the business approval page. Objects using the business approval authority can generate approval information about the synchronous approval event by operating the business approval page. For example, the business approval page can display two controls, "Approval Passed" and "Approval Failed," to allow objects to determine the approval result of the synchronous approval event; the business approval page can display a remarks area where objects can enter remarks about the synchronous approval event. Additionally, the business approval page can provide a "confirm" control. After the object completes the approval process, it can trigger the "confirm" control to send the approval information of the synchronous approval event to the main chain. Furthermore, the main chain node can generate an approval event block containing the approval information of this synchronous approval event.

[0088] In one embodiment, the business approval end can use a hash algorithm to encrypt the approval information of the synchronous approval event to obtain third digest data, and then use its private key to sign the third digest data to obtain third signature data. The third signature data and the approval information of the synchronous approval event are then sent to the main chain. The main chain node uses the public key of the business approval end to decrypt the third signature data to obtain third decrypted data, and uses a hash algorithm to encrypt the approval information of the synchronous approval event to obtain third encrypted data. When the third encrypted data and the third decrypted data match, the signature verification passes, and the main chain node obtains the approval information of the synchronous approval event. This embodiment prevents illegal data from being written to the main chain, ensuring the reliability of the main chain data.

[0089] In one embodiment, if the target business requires automatic approval, an approval strategy can be selected according to the instructions of the event information of the synchronous approval event. Specifically, different business types can have their own corresponding approval strategies, and each approval strategy runs in the main chain in the form of a smart contract. The event information of the synchronous approval event can include the contract address of the smart contract that processes the target business, through which the corresponding approval strategy can be selected (i.e., the corresponding smart contract is called). Further, the target business is approved according to the selected approval strategy. For example, the called smart contract can obtain the data required for the target business approval from the business data of the target business, determine whether each piece of data in the data required for the target business approval meets the preset approval conditions, and determine the approval result of the synchronous approval event based on the judgment result. If the target business is a tax refund business, if errors are found in the declaration data or the applicant's identity information, it can be determined that the preset approval conditions are not met, and the approval result of the synchronous approval event is approval failure. When the approval result of the synchronous approval event is obtained, approval information about the synchronous approval event can be returned based on the approval result, which can include remarks about the approval result. Finally, the main chain node can generate an approval event block for the approval information of the synchronous approval event.

[0090] Smart contracts are digital versions of traditional contracts. They are computer programs that run on a blockchain database and can execute themselves when conditions written in their source code are met. Once a smart contract is written, it can be trusted by the recipient, and its terms cannot be changed. Deploying a smart contract can be understood as deploying the agreed-upon contract on the blockchain after it has been approved by the blockchain network's consensus mechanism; running a smart contract can be understood as automatically executing the contract when its execution conditions are met and recording the results on the blockchain.

[0091] S505. The subchain node of the subchain receives the second cross-chain data sent by the relay node of the main chain and broadcasts the second cross-chain data in the subchain. The second cross-chain data is used to trigger the subchain node of the subchain to complete the business processing of the target business.

[0092] After generating an approval event block containing the approval information for a synchronous approval event, the main chain node can broadcast an approval completion event within the main chain. This broadcast informs the relay nodes on the main chain that the target business has been approved. At this point, the relay nodes can retrieve the approval event block from the main chain, generate second cross-chain data based on the approval information from the synchronous approval event included in the block, and then send this second cross-chain data to the child chain.

[0093] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information of the synchronous approval event, and second verification data regarding approval information of the synchronous approval event determined through the approval event block.

[0094] The second transaction data includes: event information of the approval information of the synchronous approval event, event information of the synchronous approval event, and first transaction data regarding the target business. Specifically, the data packaged into the approval event block is called the second transaction data. The second verification data regarding the approval information of the synchronous approval event determined by the approval event block includes: the Merkle tree root value of the approval event block and the verification path of the second transaction data. This verification path of the second transaction data is obtained based on the Merkle tree in the approval event block. Specifically, the leaf node corresponding to the second transaction data in the Merkle tree of the approval event block can be determined, and the parent node can be found sequentially upwards from the leaf node to determine the multiple path nodes traversed from the leaf node to the root node. Nodes that share a common parent node with the path nodes are taken as branch nodes, and the various branch nodes can constitute the verification path of the second transaction data.

[0095] After receiving the second cross-chain data, the sub-chain nodes can verify the second transaction data based on the second verification data. Once the second transaction data passes verification, it is broadcast within the sub-chain. In one embodiment, the process of verifying the second transaction data based on the second verification data includes: when the verification root value obtained from the verification path included in the second transaction data and the second verification data matches the Merkle tree root value included in the second verification data, it indicates that the second transaction data has not been tampered with, and the verification of the second transaction data passes. When the verification root value obtained from the verification path included in the second transaction data and the second verification data does not match the Merkle tree root value included in the second verification data, it indicates that the second transaction data has been tampered with, and the verification of the second transaction data fails. The processing logic for obtaining the verification root value based on the verification path included in the second transaction data and the second verification data is consistent with the processing logic for obtaining the verification root value based on the verification path included in the first transaction data and the first verification data in S503, as described in the relevant section of S503. Using this embodiment, the relay nodes of the main chain can be prevented from submitting tampered second transaction data, ensuring the reliability of sub-chain data and the security of sub-chain business processing.

[0096] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information for a synchronized approval event, and second verification data regarding approval information for the synchronized approval event determined by the approval event block. The second transaction data includes: event information of the approval information, event information of the synchronized approval event, first transaction data regarding the target business, and first verification data regarding the target business determined by the business block. After receiving the second cross-chain data, a sub-chain node can verify the second transaction data based on the second verification data. After the second transaction data passes verification, it broadcasts the second cross-chain data in the sub-chain. Verifying the second transaction data based on the second verification data includes: verifying the second transaction data based on the second verification data and verifying the first transaction data based on the first verification data. If both verifications pass, the second cross-chain data is broadcast in the sub-chain.

[0097] The process of verifying the second transaction data based on the second verification data includes: when the verification root value obtained from the verification path included in the second transaction data and the second verification data matches the Merkle tree root value included in the second verification data, it indicates that the second transaction data has not been tampered with, and the verification of the second transaction data passes. When the verification root value obtained from the verification path included in the second transaction data and the second verification data does not match the Merkle tree root value included in the second verification data, it indicates that the second transaction data has been tampered with, and the verification of the second transaction data fails. The process of verifying the first transaction data based on the first verification data includes: obtaining the verification root value based on the first transaction data and the verification path included in the first verification data. For example... Figure 6The verification path for the first transaction data shown includes hash value 3 to hash value 12. After obtaining the first transaction data in the first cross-chain data, the main chain node can perform a hash transformation on the first transaction data to obtain hash value 4′. By concatenating hash value 4′ and hash value 3 and performing a hash transformation, hash value 34′ is obtained. By concatenating hash value 34′ and hash value 12 and performing a hash transformation, hash value 1234′ is obtained. This hash value 1234′ is the verification root value obtained based on the verification path included in the first transaction data and the first verification data. If the obtained verification root value is consistent with the Merkle tree root value included in the first verification data, for example, hash value 1234′ is consistent with hash value 1234, it indicates that the first transaction data in the first cross-chain data is tamper-proof. The main chain node can determine that the verification of the first transaction data has passed, execute S504, and generate an approval event block for the approval information of the synchronous approval event. If the obtained verification root value is inconsistent with the Merkle tree root value included in the first verification data, it indicates that the first transaction data in the first cross-chain data has been tampered with, and the verification of the first transaction data has failed. This embodiment can prevent the main chain relay nodes from submitting tampered first and second transaction data, ensuring the reliability of sub-chain data and the security of sub-chain business processing.

[0098] In a feasible implementation, the main chain's relay nodes can send the second cross-chain data and the fourth signature data to the sub-chain. The fourth signature data can be obtained by the main chain's relay nodes signing the fourth digest data using their private key. The fourth digest data is obtained by encrypting the second cross-chain data using a hash algorithm. The sub-chain nodes can decrypt the fourth signature data using the main chain's relay nodes' public key to obtain the fourth decrypted data. They then encrypt the second cross-chain data using a hash algorithm to obtain the fourth encrypted data. When the fourth decrypted data and the fourth encrypted data match, the signature verification is considered successful. Only after the signature verification is successful can the sub-chain nodes obtain the second cross-chain data and execute the subsequent verification process for the second transaction data. This prevents illegal data from being written to the sub-chain and improves the reliability of the sub-chain data.

[0099] In one feasible implementation, after a subchain node broadcasts the second cross-chain data within its subchain, the second cross-chain data can be consensus-uploaded onto the subchain. Subchain nodes can then retrieve the second cross-chain data from the subchain for verification. Upon successful verification of the second cross-chain data, the node obtains the approval result of the synchronous approval event included in the second cross-chain data. If the approval result is successful, the target business is processed according to the processing strategy following successful approval. For example, if the target business is a tax refund, a tax refund operation is executed upon successful approval; simultaneously, a notification message indicating successful approval is sent to the business requester of the target business. If the approval result is unsuccessful, a notification message indicating unsuccessful approval is sent to the business requester of the target business, and the business processing of the target business is terminated.

[0100] Specifically, when the verification root value obtained from the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data, it indicates that the second cross-chain data consensus or verification has passed. In one implementation, the second cross-chain data can be broadcast in the sub-chain. If a majority of sub-chain nodes (e.g., 2 / 3) agree on the second cross-chain data, then the second cross-chain data is written into the sub-chain.

[0101] In summary, the business data processing method provided in this application is applied to tax business and combined with... Figure 7 This section provides an explanation. Before executing this business data processing method, the sub-chain and main chain need to jointly negotiate a cross-chain verification contract, declaring the developed cross-chain verification program within the contract. Specifically, the cross-chain verification program declared in the sub-chain's cross-chain verification contract can be used to verify the second transaction data (which may also include the first transaction data) in the second cross-chain data sent by the main chain's relay node. The cross-chain verification program declared in the main chain's cross-chain verification contract can be used to verify the first transaction data in the first cross-chain data sent by the sub-chain's relay node. Simultaneously, business contracts deployed in both the sub-chain and main chain are used to implement event processing, such as data on-chain consensus and target business processing. This method includes:

[0102] (1) Subchain nodes can take turns acting as block producers to ensure normal transaction block production for tax-related businesses. When packaging a block, the block producer checks whether the business data of each tax-related business within the block meets the approval criteria. When the block producer packages the business data of the target business (in this case, a tax-related business) into the business block, it generates a synchronous approval event for the target business in response to the target business data meeting the approval criteria. At this time, all clients subscribing to the synchronous approval event and the relay nodes of the subchain can receive the event message. Clients subscribing to the synchronous approval event can generate a notification message indicating that the target business is pending approval.

[0103] (2) After the synchronous approval event is broadcast in the subchain, the business contract that executes the target business cannot continue to reach consensus, but the business contract that handles other businesses can continue to reach consensus in order to complete the processing of other businesses.

[0104] (3) The relay node of the sub-chain that receives the synchronous approval event can obtain the first cross-chain data in the sub-chain and forward the first cross-chain data to the cross-chain verification contract of the main chain. The first transaction data in the first cross-chain data is verified in the cross-chain verification contract of the main chain. After the verification is passed, the first cross-chain data is consensus-uploaded to the main chain to complete the on-chain confirmation of the synchronous approval event of the sub-chain and the business status of the sub-chain.

[0105] (4) The relay nodes of the main chain can continue to trigger the business contracts in the main chain to approve the synchronous approval event and obtain the approval information of the synchronous approval event. Alternatively, the synchronous approval event can also be manually approved to obtain the approval information of the synchronous approval event. After the synchronous approval event is approved, the approval completion event can be broadcast in the main chain, and an approval event block containing the approval information of the synchronous approval event can be generated.

[0106] (5) After the main chain relay captures the approval completion event, it generates the second cross-chain data according to the approval event block and sends the second cross-chain data to the cross-chain verification contract of the sub-chain. After the cross-chain verification contract of the sub-chain verifies the second transaction data (which may also include the first transaction data) in the second cross-chain data, it broadcasts the second cross-chain data in the sub-chain to achieve consensus on the second cross-chain data in the sub-chain.

[0107] (6) Once the second cross-chain data is successfully uploaded to the chain, the main chain relay can trigger the business contract of the sub-chain to verify the second cross-chain data. After the second cross-chain data is verified, the approval result in the second cross-chain data marks the previous synchronous approval event as completed. At this time, the business contract can continue to process the business. Specifically, when the synchronous approval event is approved, the business contract continues to process the target business; when the synchronous approval event is rejected, the business contract processes the next business.

[0108] By employing the method described in this application, when a sub-chain's business requires approval from the main chain, a synchronous approval event can be generated using the blockchain's event mechanism. This synchronous approval event enables the main chain and sub-chain, which were originally executing asynchronously, to synchronize their states, allowing the sub-chain to be subject to the main chain's security governance at the business level. Simultaneously, during the approval process, both sub-chain nodes and main chain nodes verify the received data, and only proceed with the business approval process after successful verification. This ensures the security of business data processing and significantly reduces the possibility of unauthorized tampering or destruction of business approval-related data. Furthermore, in scenarios unrelated to main chain governance, this application can leverage the high performance and convenience of independent consensus on the sub-chain for business operations.

[0109] It is understood that in the specific embodiments of this application, business data and other related data involving the target business are required to obtain permission or consent from the target when the above embodiments of this application are applied to specific products or technologies, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0110] The methods of the embodiments of this application have been described in detail above. To facilitate better implementation of the above solutions of the embodiments of this application, the apparatus of the embodiments of this application is provided below. Please refer to... Figure 8 , Figure 8 This is a schematic diagram of the structure of a business data processing device based on a blockchain network according to an embodiment of this application. The blockchain network includes a main chain and at least one sub-chain. The main chain includes multiple main chain nodes, and the sub-chain includes multiple sub-chain nodes. The main chain nodes communicate with one or more sub-chain nodes through relay nodes of the main chain, and the sub-chain nodes communicate with one or more main chain nodes through relay nodes of the sub-chain. In one embodiment, the business data processing device 80 based on the blockchain network corresponds to a sub-chain node of the sub-chain, and the business data processing device 80 based on the blockchain network may include:

[0111] Processing unit 801 is used to generate a synchronous approval event for the target business in response to the business data of the target business corresponding to the business block meeting the approval conditions.

[0112] Processing unit 801 is configured to broadcast the synchronous approval event on the sub-chain, wherein the synchronous approval event is configured to trigger the relay node of the sub-chain to generate first cross-chain data based on the event information of the synchronous approval event and send it to the main chain; the first cross-chain data is configured to instruct the main chain node of the main chain to respond to the first cross-chain data to generate an approval event block containing the approval information of the synchronous approval event;

[0113] The receiving unit 802 is used to receive the second cross-chain data sent by the relay node of the main chain;

[0114] The processing unit 801 is further configured to broadcast the second cross-chain data in the sub-chain, the second cross-chain data being used to trigger the sub-chain nodes of the sub-chain to complete the business processing of the target business, the second cross-chain data being generated by the relay node of the main chain based on the approval event block.

[0115] In one embodiment, the first cross-chain data includes: event information of the synchronous approval event, first transaction data about the target business, and first verification data about the target business determined by the business block, wherein the first transaction data is generated based on the business data of the target business; the first cross-chain data is further used to instruct the main chain node of the main chain to generate the approval event block after the first transaction data has been verified; wherein, the verification of the first transaction data is passed when the verification root value obtained based on the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data.

[0116] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information of the synchronous approval event, and second verification data regarding approval information of the synchronous approval event determined by the approval event block; the second transaction data includes: event information of the approval information, event information of the synchronous approval event, and first transaction data regarding the target business; the processing unit 801 is configured to: verify the second transaction data according to the second verification data; after the second transaction data is verified, trigger the broadcasting of the second cross-chain data in the sub-chain; wherein, when the verification root value obtained according to the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data, the verification of the second transaction data is successful.

[0117] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information of the synchronous approval event, and second verification data regarding approval information of the synchronous approval event determined by the approval event block; the second transaction data includes: event information of the approval information, event information of the synchronous approval event, first transaction data regarding the target business, and first verification data regarding the target business determined by the business block; the processing unit 801 is specifically used to: verify the second transaction data according to the second verification data, and verify the first transaction data according to the first verification data; if both verifications pass, then trigger the broadcasting of the second cross-chain data in the sub-chain; wherein, when the verification root value obtained according to the verification path included in the second transaction data and the second verification data is consistent with the Merkle root value included in the second verification data, the verification of the second transaction data passes; when the verification root value obtained according to the verification path included in the first transaction data and the first verification data is consistent with the Merkle root value included in the first verification data, the verification of the first transaction data passes.

[0118] In one embodiment, the processing unit 801 is specifically configured to: verify the second cross-chain data; in response to the successful verification of the second cross-chain data, obtain the approval result of the synchronous approval event in the second cross-chain data based on the approval information about the synchronous approval event included in the second cross-chain data; if the approval result is successful, process the target business according to the processing strategy after successful approval, and send a notification message of successful approval to the business request end of the target business; if the approval result is unsuccessful, send a notification message indicating unsuccessful approval to the business request end of the target business.

[0119] In one embodiment, the processing unit 801 is specifically configured to: broadcast the business block in the sub-chain; generate a synchronization event block of the synchronous approval event and broadcast the synchronization event block in the sub-chain; generate a notification message of the synchronous approval event and send the notification message of the synchronous approval event to the business request end of the target business, wherein the notification message of the synchronous approval event is used to indicate that the approval status of the target business is pending approval.

[0120] In one embodiment, the blockchain-based business data processing device 80 corresponds to a main chain node of the main chain, and the blockchain-based business data processing device 80 may include:

[0121] The receiving unit 802 is used to receive the first cross-chain data sent by the relay node of the sub-chain. The first cross-chain data is generated by the relay node of the sub-chain triggered by the synchronous approval event of the target business. The synchronous approval event is generated by the sub-chain node of the sub-chain in response to the business data of the target business corresponding to the business block meeting the approval conditions.

[0122] Processing unit 801 is used to respond to the first cross-chain data and generate an approval event block of the approval information of the synchronous approval event; the approval event block is used to trigger the relay node of the main chain to generate second cross-chain data according to the approval event block and send it to the sub-chain; the second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business.

[0123] In one embodiment, the processing unit 801 is specifically configured to: send an approval notification message to the business approval end of the target business, the approval notification message including first transaction data included in the first cross-chain data and event information of the synchronous approval event, the approval notification message being used to instruct the business approval end to generate a business approval page based on the event information of the synchronous approval event and / or the first transaction data; and obtain approval information about the synchronous approval event generated on the business approval page.

[0124] The receiving unit 802 is specifically used to: receive the approval information of the synchronous approval event sent by the business approval terminal, and generate an approval event block of the approval information of the synchronous approval event.

[0125] In one embodiment, the processing unit 801 is specifically configured to: select an approval strategy according to the event information of the synchronous approval event; approve the target business according to the selected approval strategy, and return approval information about the synchronous approval event according to the approval result; and generate an approval event block of the approval information of the synchronous approval event.

[0126] In one embodiment, the first cross-chain data includes: event information of the synchronous approval event, first transaction data about the target business, and first verification data about the target business determined by the business block, wherein the first transaction data is generated based on the business data of the target business; the processing unit 801 is specifically used to: verify the first transaction data based on the first verification data; after the first transaction data is verified, trigger the execution of the approval event block that generates the approval information of the synchronous approval event; wherein, when the verification root value obtained based on the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data, the verification of the first transaction data is passed.

[0127] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information of the synchronous approval event, and second verification data regarding approval information of the synchronous approval event determined by the approval event block; the second transaction data includes: event information of the approval information, event information of the synchronous approval event, and first transaction data regarding the target business; the second cross-chain data is used to instruct the sub-chain node of the sub-chain to trigger the broadcasting of the second cross-chain data in the sub-chain after the second transaction data has been verified; wherein, the verification of the second transaction data is passed when the verification root value obtained according to the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data.

[0128] In one embodiment, the second cross-chain data includes: second transaction data regarding the approval information of the synchronous approval event, and second verification data regarding the approval information of the synchronous approval event determined through the approval event block;

[0129] The second transaction data includes: event information of the approval information, event information of the synchronous approval event, first transaction data regarding the target business, and first verification data regarding the target business determined by the business block; the second cross-chain data is used to instruct the sub-chain node of the sub-chain to trigger the broadcasting of the second cross-chain data in the sub-chain after the first transaction data and the second transaction data have been verified; wherein, the verification of the second transaction data is successful when the verification root value obtained according to the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data; the verification of the first transaction data is successful when the verification root value obtained according to the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data.

[0130] It is understood that the functions of each functional unit of the data processing device described in the embodiments of this application can be specifically implemented according to the methods in the above method embodiments, and the specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0131] The business data processing method proposed in this application can be implemented based on a blockchain network. Through the defined interaction process between the main chain and the sub-chain, the data processing of approval business can be realized based on the blockchain network. This allows the business logic of the sub-chain to be managed by the main chain during the business approval process, ensuring the security of cross-chain business processing and greatly reducing the possibility of business approval-related data being illegally tampered with or destroyed.

[0132] like Figure 9 As shown, Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The internal structure of the computer device 90 is as follows: Figure 9 As shown, it includes: one or more processors 901, a memory 902, and a communication interface 903. The processors 901, memory 902, and communication interface 903 can be connected via a bus 904 or other means; this embodiment of the application takes connection via bus 904 as an example.

[0133] The processor 901 (or CPU, Central Processing Unit) is the computing and control core of the computer device 90. It can parse various instructions within the computer device 90 and process various data. For example, the CPU can parse power-on / off commands sent to the computer device 90 and control the computer device 90 to perform power-on / off operations; it can also transmit various interactive data between internal structures of the computer device 90, and so on. The communication interface 903 may optionally include standard wired interfaces or wireless interfaces (such as Wi-Fi, mobile communication interfaces, etc.), and is controlled by the processor 901 for sending and receiving data. The memory 902 is the storage device in the computer device 90, used to store computer programs and data. It is understood that the memory 902 here can include the computer device 90's built-in memory, or it can include extended memory supported by the computer device 90. The memory 902 provides storage space, which stores the operating system of the computer device 90, including but not limited to: Windows systems, Linux systems, etc., which this application does not limit. In one embodiment, the computer device 90 corresponds to a sub-chain node of a sub-chain in a blockchain network. The blockchain network includes a main chain and at least one sub-chain. The main chain includes multiple main chain nodes, and the sub-chain includes multiple sub-chain nodes. The main chain nodes communicate with one or more sub-chain nodes through relay nodes of the main chain. Similarly, the sub-chain nodes communicate with one or more main chain nodes of the main chain through relay nodes of the sub-chain. In this case, the processor 901 executes the following operations by running a computer program stored in memory 902:

[0134] In response to the business data of the target business corresponding to the business block meeting the approval conditions, a synchronous approval event for the target business is generated;

[0135] The synchronous approval event is broadcast on the sub-chain. The synchronous approval event is used to trigger the relay node of the sub-chain to generate first cross-chain data based on the event information of the synchronous approval event and send it to the main chain. The first cross-chain data is used to instruct the main chain node of the main chain to respond to the first cross-chain data to generate an approval event block of the approval information of the synchronous approval event.

[0136] The system receives second cross-chain data sent by the relay node of the main chain and broadcasts the second cross-chain data in the sub-chain. The second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business. The second cross-chain data is generated by the relay node of the main chain based on the approval event block.

[0137] In one embodiment, the first cross-chain data includes: event information of the synchronous approval event, first transaction data about the target business, and first verification data about the target business determined by the business block, wherein the first transaction data is generated based on the business data of the target business;

[0138] The first cross-chain data is also used to instruct the main chain node of the main chain to generate the approval event block after the first transaction data has been verified; wherein, the verification of the first transaction data is passed when the verification root value obtained according to the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data.

[0139] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information of the synchronous approval event, and second verification data regarding approval information of the synchronous approval event determined by the approval event block; the second transaction data includes: event information of the approval information, event information of the synchronous approval event, and first transaction data regarding the target business; the processor 901 is specifically used to: verify the second transaction data according to the second verification data; after the second transaction data is verified, trigger the broadcasting of the second cross-chain data in the sub-chain; wherein, when the verification root value obtained according to the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data, the verification of the second transaction data is passed.

[0140] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information of the synchronous approval event, and second verification data regarding approval information of the synchronous approval event determined by the approval event block; the second transaction data includes: event information of the approval information, event information of the synchronous approval event, first transaction data regarding the target business, and first verification data regarding the target business determined by the business block; the processor 901 is specifically configured to: verify the second transaction data according to the second verification data, and verify the first transaction data according to the first verification data; if both verifications pass, then trigger the broadcasting of the second cross-chain data in the sub-chain; wherein, when the verification root value obtained according to the verification path included in the second transaction data and the second verification data is consistent with the Merkle root value included in the second verification data, the verification of the second transaction data passes; when the verification root value obtained according to the verification path included in the first transaction data and the first verification data is consistent with the Merkle root value included in the first verification data, the verification of the first transaction data passes.

[0141] In one embodiment, the processor 901 is specifically configured to: verify the second cross-chain data; in response to the successful verification of the second cross-chain data, obtain the approval result of the synchronous approval event in the second cross-chain data based on the approval information about the synchronous approval event included in the second cross-chain data; if the approval result is successful, process the target business according to the processing strategy after successful approval, and send a notification message of successful approval to the business request end of the target business; if the approval result is unsuccessful, send a notification message indicating unsuccessful approval to the business request end of the target business.

[0142] In one embodiment, the processor 901 is specifically configured to: broadcast the business block in the subchain; generate a synchronization event block of the synchronization approval event and broadcast the synchronization event block in the subchain; generate a notification message of the synchronization approval event and send the notification message of the synchronization approval event to the business request end of the target business, wherein the notification message of the synchronization approval event is used to indicate that the approval status of the target business is pending approval.

[0143] In one embodiment, the computer device 90 corresponds to a master chain node in a blockchain network, which includes a master chain and at least one sub-chain. The master chain includes multiple master chain nodes, and the sub-chain includes multiple sub-chain nodes. The master chain nodes of the master chain communicate with one or more sub-chain nodes of the sub-chain through relay nodes of the master chain, and the sub-chain nodes of the sub-chain communicate with one or more master chain nodes of the master chain through relay nodes of the sub-chain. Then, the processor 901 executes the following operations by running a computer program stored in the memory 902:

[0144] The relay node of the sub-chain receives the first cross-chain data sent by the relay node of the sub-chain. The first cross-chain data is generated by the relay node of the sub-chain triggered by the synchronous approval event of the target business. The synchronous approval event is generated by the sub-chain node of the sub-chain in response to the business data of the target business corresponding to the business block meeting the approval conditions.

[0145] In response to the first cross-chain data, an approval event block is generated to provide approval information for the synchronous approval event. The approval event block is used to trigger the relay node of the main chain to generate second cross-chain data based on the approval event block and send it to the sub-chain. The second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business.

[0146] In one embodiment, the processor 901 is specifically configured to: send an approval notification message to the business approval terminal of the target business, the approval notification message including first transaction data included in the first cross-chain data and event information of the synchronous approval event, the approval notification message being used to instruct the business approval terminal to generate a business approval page based on the event information of the synchronous approval event and / or the first transaction data; obtain approval information about the synchronous approval event generated on the business approval page; receive the approval information of the synchronous approval event sent by the business approval terminal, and generate an approval event block of the approval information of the synchronous approval event.

[0147] In one embodiment, the processor 901 is specifically configured to: select an approval strategy according to the indication of the event information of the synchronous approval event; approve the target business according to the selected approval strategy, and return approval information about the synchronous approval event according to the approval result; and generate an approval event block of the approval information of the synchronous approval event.

[0148] In one embodiment, the first cross-chain data includes: event information of the synchronous approval event, first transaction data about the target business, and first verification data about the target business determined by the business block, wherein the first transaction data is generated based on the business data of the target business; the processor 901 is specifically configured to: verify the first transaction data based on the first verification data; after the first transaction data is verified, trigger the execution of an approval event block that generates approval information of the synchronous approval event; wherein, when the verification root value obtained based on the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data, the verification of the first transaction data is successful.

[0149] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information of the synchronous approval event, and second verification data regarding approval information of the synchronous approval event determined by the approval event block; the second transaction data includes: event information of the approval information, event information of the synchronous approval event, and first transaction data regarding the target business; the second cross-chain data is used to instruct the sub-chain node of the sub-chain to trigger the broadcasting of the second cross-chain data in the sub-chain after the second transaction data has been verified; wherein, the verification of the second transaction data is passed when the verification root value obtained according to the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data.

[0150] In one embodiment, the second cross-chain data includes: second transaction data regarding approval information of the synchronous approval event, and second verification data regarding approval information of the synchronous approval event determined by the approval event block; the second transaction data includes: event information of the approval information, event information of the synchronous approval event, first transaction data regarding the target business, and first verification data regarding the target business determined by the business block; the second cross-chain data is used to instruct the sub-chain node of the sub-chain to trigger the broadcasting of the second cross-chain data in the sub-chain after the first transaction data and the second transaction data have been verified; wherein, the verification of the second transaction data is passed when the verification root value obtained according to the verification path included in the second transaction data and the second verification data is consistent with the Merkle root value included in the second verification data; the verification of the first transaction data is passed when the verification root value obtained according to the verification path included in the first transaction data and the first verification data is consistent with the Merkle root value included in the first verification data.

[0151] In specific implementations, the processor 901, memory 902, and communication interface 903 described in the embodiments of this application can execute the implementation of the computer device described in the business data processing method based on a blockchain network provided in the embodiments of this application, or the implementation of the business data processing device based on a blockchain network provided in the embodiments of this application, which will not be repeated here.

[0152] The business data processing method proposed in this application can be implemented based on a blockchain network. Through the defined interaction process between the main chain and the sub-chain, the data processing of approval business can be realized based on the blockchain network. This allows the business logic of the sub-chain to be managed by the main chain during the business approval process, ensuring the security of cross-chain business processing and greatly reducing the possibility of business approval-related data being illegally tampered with or destroyed.

[0153] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the business data processing method based on a blockchain network as described in this application. The specific implementation can be found in the preceding description and will not be repeated here.

[0154] This application also provides a computer program product, which includes a computer program or computer instructions. When executed by a processor, the computer program or computer instructions implement the steps of the business data processing method based on a blockchain network provided in this application. The specific implementation method can be found in the foregoing description and will not be repeated here.

[0155] This application also provides a computer program comprising 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 business data processing method based on a blockchain network provided in this application. The specific implementation can be found in the preceding description and will not be repeated here.

[0156] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0157] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

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

Claims

1. A business data processing method based on a blockchain network, characterized in that, The blockchain network includes a main chain and at least one sub-chain. The main chain and at least one sub-chain belong to a consensus network within the blockchain network. The consensus network includes a consensus main network and at least one consensus sub-network. The consensus main network corresponds to the main chain, and each consensus sub-network corresponds to a sub-chain. The main chain includes multiple main chain nodes, which are consensus nodes within the consensus main network. Each sub-chain includes multiple sub-chain nodes, which are consensus nodes within the consensus sub-network. The main chain nodes of the main chain communicate with one or more sub-chain nodes of the sub-chain through relay nodes of the main chain. The sub-chain nodes of the sub-chain communicate with one or more main chain nodes of the main chain through relay nodes of the sub-chain. The method includes: In response to the business data of the target business corresponding to the business block meeting the approval conditions, a synchronous approval event for the target business is generated; The synchronous approval event is broadcast on the sub-chain. The synchronous approval event is used to trigger the relay node of the sub-chain to generate first cross-chain data based on the event information of the synchronous approval event and send it to the main chain. The first cross-chain data is used to instruct the main chain node of the main chain to respond to the first cross-chain data to generate an approval event block of the approval information of the synchronous approval event. The system receives second cross-chain data sent by the relay node of the main chain and broadcasts the second cross-chain data in the sub-chain. The second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business. The second cross-chain data is generated by the relay node of the main chain based on the approval event block.

2. The method as described in claim 1, characterized in that, The first cross-chain data includes: event information of the synchronous approval event, first transaction data about the target business, and first verification data about the target business determined by the business block, wherein the first transaction data is generated based on the business data of the target business; The first cross-chain data is also used to instruct the main chain node of the main chain to generate the approval event block after the first transaction data has been verified. Specifically, the verification of the first transaction data is successful when the verification root value obtained from the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data.

3. The method as described in claim 1, characterized in that, The second cross-chain data includes: second transaction data regarding the approval information of the synchronous approval event, and second verification data regarding the approval information of the synchronous approval event determined through the approval event block; The second transaction data includes: event information of the approval information, event information of the synchronous approval event, and first transaction data related to the target business; Before broadcasting the second cross-chain data in the sub-chain, the method further includes: The second transaction data is verified based on the second verification data; After the second transaction data is verified, the broadcast of the second cross-chain data in the sub-chain is triggered. Specifically, the verification of the second transaction data is successful when the verification root value obtained from the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data.

4. The method as described in claim 1, characterized in that, The second cross-chain data includes: second transaction data regarding the approval information of the synchronous approval event, and second verification data regarding the approval information of the synchronous approval event determined through the approval event block; The second transaction data includes: event information of the approval information, event information of the synchronous approval event, first transaction data regarding the target business, and first verification data regarding the target business determined through the business block; Before broadcasting the second cross-chain data in the sub-chain, the method further includes: The second transaction data is verified based on the second verification data, and the first transaction data is verified based on the first verification data; If all verifications pass, the execution of broadcasting the second cross-chain data in the sub-chain is triggered; Specifically, the verification of the second transaction data is successful when the verification root value obtained from the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data; the verification of the first transaction data is successful when the verification root value obtained from the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data.

5. The method according to any one of claims 1-4, characterized in that, After broadcasting the second cross-chain data in the sub-chain, the method further includes: Verify the second cross-chain data; In response to the successful verification of the second cross-chain data, the approval result of the synchronous approval event in the second cross-chain data is obtained based on the approval information about the synchronous approval event included in the second cross-chain data; If the approval result is "approved", then the target business will be processed according to the processing strategy after approval, and the approval notification message will be sent to the business request end of the target business. If the approval result is that the approval is not approved, a notification message indicating that the approval is not approved will be sent to the business request terminal of the target business.

6. The method according to any one of claims 1-4, characterized in that, After generating the synchronous approval event for the target service, the method further includes: Broadcast the service block in the sub-chain; Generate a synchronization event block for the synchronous approval event, and broadcast the synchronization event block in the sub-chain; A notification message for the synchronous approval event is generated and sent to the business request end of the target business. The notification message for the synchronous approval event is used to indicate that the approval status of the target business is pending approval.

7. A business data processing method based on a blockchain network, characterized in that, The blockchain network includes a main chain and at least one sub-chain. The main chain and at least one sub-chain belong to a consensus network within the blockchain network. The consensus network includes a consensus main network and at least one consensus sub-network. The consensus main network corresponds to the main chain, and each consensus sub-network corresponds to a sub-chain. The main chain includes multiple main chain nodes, which are consensus nodes within the consensus main network. Each sub-chain includes multiple sub-chain nodes, which are consensus nodes within the consensus sub-network. The main chain nodes of the main chain communicate with one or more sub-chain nodes of the sub-chain through relay nodes of the main chain. The sub-chain nodes of the sub-chain communicate with one or more main chain nodes of the main chain through relay nodes of the sub-chain. The method includes: The relay node of the sub-chain receives the first cross-chain data sent by the relay node of the sub-chain. The first cross-chain data is generated by the relay node of the sub-chain triggered by the synchronous approval event of the target business. The synchronous approval event is generated by the sub-chain node of the sub-chain in response to the business data of the target business corresponding to the business block meeting the approval conditions. In response to the first cross-chain data, an approval event block is generated to provide approval information for the synchronous approval event. The approval event block is used to trigger the relay node of the main chain to generate second cross-chain data based on the approval event block and send it to the sub-chain. The second cross-chain data is used to trigger the sub-chain node of the sub-chain to complete the business processing of the target business.

8. The method as described in claim 7, characterized in that, The approval event block that generates the approval information for the synchronous approval event includes: Send an approval notification message to the business approval end of the target business. The approval notification message includes the first transaction data included in the first cross-chain data and the event information of the synchronous approval event. The approval notification message is used to instruct the business approval end to generate a business approval page based on the event information of the synchronous approval event and / or the first transaction data. Obtain approval information regarding the synchronous approval event generated on the business approval page; Receive approval information of the synchronous approval event sent by the business approval terminal, and generate an approval event block of the approval information of the synchronous approval event.

9. The method as described in claim 7, characterized in that, The approval event block that generates the approval information for the synchronous approval event includes: Select the approval strategy according to the instructions in the event information of the synchronous approval event; The target business is approved according to the selected approval strategy, and approval information about the synchronous approval event is returned based on the approval result; An approval event block that generates the approval information for the synchronous approval event.

10. The method according to any one of claims 7-9, characterized in that, The first cross-chain data includes: event information of the synchronous approval event, first transaction data about the target business, and first verification data about the target business determined by the business block, wherein the first transaction data is generated based on the business data of the target business; Before generating the approval event block containing the approval information for the synchronous approval event, the method further includes: The first transaction data is verified based on the first verification data; After the first transaction data is verified, the approval event block that generates the approval information for the synchronous approval event is triggered. Specifically, the verification of the first transaction data is successful when the verification root value obtained from the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data.

11. The method according to any one of claims 7-9, characterized in that, The second cross-chain data includes: second transaction data regarding the approval information of the synchronous approval event, and second verification data regarding the approval information of the synchronous approval event determined through the approval event block; The second transaction data includes: event information of the approval information, event information of the synchronous approval event, and first transaction data related to the target business; The second cross-chain data is used to instruct the sub-chain node of the sub-chain to trigger the broadcasting of the second cross-chain data in the sub-chain after the second transaction data has been verified. Specifically, the verification of the second transaction data is successful when the verification root value obtained from the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data.

12. The method according to any one of claims 7-9, characterized in that, The second cross-chain data includes: second transaction data regarding the approval information of the synchronous approval event, and second verification data regarding the approval information of the synchronous approval event determined through the approval event block; The second transaction data includes: event information of the approval information, event information of the synchronous approval event, first transaction data regarding the target business, and first verification data regarding the target business determined through the business block; The second cross-chain data is used to instruct the sub-chain node of the sub-chain to trigger the broadcasting of the second cross-chain data in the sub-chain after the first transaction data and the second transaction data have been verified. Specifically, the verification of the second transaction data is successful when the verification root value obtained from the verification path included in the second transaction data and the second verification data is consistent with the Merkle tree root value included in the second verification data; the verification of the first transaction data is successful when the verification root value obtained from the verification path included in the first transaction data and the first verification data is consistent with the Merkle tree root value included in the first verification data.

13. A business data processing device based on a blockchain network, characterized in that, It includes units for implementing the business data processing method based on a blockchain network as described in any one of claims 1-6, or includes units for implementing the business data processing method based on a blockchain network as described in any one of claims 7-12.

14. A computer device, characterized in that, The computer device includes a memory, a communication interface, and a processor, wherein the memory, the communication interface, and the processor are interconnected; the memory stores a computer program, and the processor calls the computer program stored in the memory to implement the business data processing method based on a blockchain network as described in any one of claims 1-6, or to implement the business data processing method based on a blockchain network as described in any one of claims 7-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the business data processing method based on a blockchain network as described in any one of claims 1-6, or implements the business data processing method based on a blockchain network as described in any one of claims 7-12.

16. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the business data processing method based on a blockchain network as described in any one of claims 1-6, or implement the business data processing method based on a blockchain network as described in any one of claims 7-12.

Images