Blockchain-based block processing method, device and equipment, medium and product

Abstract

The application provides a blockchain-based block processing method, device and equipment, medium and product. The method comprises the following steps: if a target service meets a cross-chain consensus condition, a first consensus node of a first service branch chain generates a cross-chain service block for the target service, performs pre-commitment processing on the cross-chain service block based on the first service branch chain, and stores the cross-chain service block in a first cross-chain storage space corresponding to the first service branch chain; a second consensus node of a second service branch chain acquires the cross-chain service block from the first cross-chain storage space, performs cross-chain consensus on the cross-chain service block, stores a cross-chain consensus result in a second cross-chain storage space corresponding to the second service branch chain, and acquires the cross-chain consensus result from the second cross-chain storage space, and sets a state of the cross-chain service block pre-committed to the first service branch chain based on the cross-chain consensus result. In this way, cross-chain consensus processing of cross-chain services can be realized.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to the field of blockchain technology, and in particular to blockchain-based block processing methods, block processing devices, computer equipment, computer-readable storage media, and computer program products. Background Technology

[0002] With the rapid development of blockchain technology, more and more users and enterprises are choosing to store data on blockchain networks to prevent data tampering. Currently, blockchain networks use blockchains to store data from different business types; for example, a blockchain network can use business branch chains corresponding to different business types to store data for those different business types. However, for multi-chain blockchain networks, how to handle cross-chain transactions remains a problem to be solved. Summary of the Invention

[0003] This application provides a blockchain-based block processing method, apparatus, device, medium, and product, which can realize cross-chain consensus processing for cross-chain businesses and improve the efficiency of cross-chain data acquisition and storage security.

[0004] On one hand, this application provides a blockchain-based block processing method. The blockchain includes a main business chain, a first business branch chain, and a second business branch chain. The first business branch chain corresponds to a first cross-chain storage space, and the second business branch chain corresponds to a second cross-chain storage space. The main chain consensus node of the main business chain allocates access permissions to the second cross-chain storage space to the first consensus node of the first business branch chain, and allocates access permissions to the first cross-chain storage space to the second consensus node of the second business branch chain. The method includes: If the target business meets the cross-chain consensus conditions, then a cross-chain business block is generated for the target business; Based on the first business branch chain, the cross-chain business block is pre-committed, and the cross-chain business block is stored in the first cross-chain storage space; Obtain the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space; wherein, the cross-chain consensus result is obtained by the second consensus node from the first cross-chain storage space to obtain the cross-chain business block and perform cross-chain consensus on the cross-chain business block; The status of the cross-chain business blocks to be submitted to the first business branch chain is set based on the cross-chain consensus result.

[0005] On one hand, this application provides another blockchain-based block processing method. The blockchain includes a main business chain, a first business branch chain, and a second business branch chain. The first business branch chain corresponds to a first cross-chain storage space, and the second business branch chain corresponds to a second cross-chain storage space. The main chain consensus node of the main business chain allocates access permissions to the second cross-chain storage space to the first consensus node of the first business branch chain, and allocates access permissions to the first cross-chain storage space to the second consensus node of the second business branch chain. The method includes: Obtain cross-chain business blocks from the first cross-chain storage space; wherein, the cross-chain business blocks are generated and stored in the first cross-chain storage space by the first consensus node for the target business when the target business meets the cross-chain consensus conditions; Perform cross-chain consensus on the cross-chain business blocks to determine the cross-chain consensus result; The cross-chain consensus result is stored in the second cross-chain storage space so that the first consensus node can obtain the cross-chain consensus result from the second cross-chain storage space and set the status of the cross-chain business block to be submitted to the first business branch chain based on the cross-chain consensus result.

[0006] On one hand, embodiments of this application provide a blockchain-based block processing device. The blockchain includes a main business chain, a first business branch chain, and a second business branch chain. The first business branch chain corresponds to a first cross-chain storage space, and the second business branch chain corresponds to a second cross-chain storage space. The main chain consensus node of the main business chain allocates access permissions to the second cross-chain storage space to the first consensus node of the first business branch chain, and allocates access permissions to the first cross-chain storage space to the second consensus node of the second business branch chain. The device includes: A processing unit is used to generate a cross-chain business block for the target business if the target business meets the cross-chain consensus conditions. The processing unit is also used to perform pre-commit processing on the cross-chain business block based on the first business branch chain; A communication unit is used to store the cross-chain business block into the first cross-chain storage space; The communication unit is further configured to obtain cross-chain consensus results regarding the cross-chain business block from the second cross-chain storage space; wherein, the cross-chain consensus results are obtained by the second consensus node obtaining the cross-chain business block from the first cross-chain storage space and performing cross-chain consensus on the cross-chain business block; The processing unit is also used to set the status of the cross-chain business blocks to be submitted to the first business branch chain based on the cross-chain consensus result.

[0007] In one embodiment, when the processing unit sets the status of the cross-chain business block to be submitted to the first business branch chain based on the cross-chain consensus result, it is specifically used for: If the cross-chain consensus of the cross-chain business block is determined to have passed based on the cross-chain consensus result, the status of the cross-chain business block pre-submitted to the first business branch chain is set to a valid status; if the cross-chain consensus of the cross-chain business block is determined to have failed based on the cross-chain consensus result, the status of the cross-chain business block pre-submitted to the first business branch chain is set to an invalid status.

[0008] In one embodiment, the processing unit is further configured to determine a consensus node for cross-chain consensus for the target business; The communication unit is further configured to obtain the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space if the consensus node for cross-chain consensus for the target business includes the business consensus node of the second business branch chain.

[0009] In one embodiment, the communication unit is further configured to send a cross-chain consensus request to the business consensus node of the second business branch chain; wherein the cross-chain consensus request carries the block identifier of the cross-chain business block; the cross-chain consensus request is used to request the business consensus node of the second business branch chain to obtain the cross-chain business block from the first cross-chain storage space based on the block identifier, and to perform cross-chain consensus on the cross-chain business block.

[0010] In one embodiment, the processing unit is further configured to perform initial consensus on the cross-chain business block; If the initial consensus result indicates that the cross-chain business block consensus has passed, then the cross-chain business block is pre-committed based on the first business branch chain, and the communication unit is triggered to store the cross-chain business block in the first cross-chain storage space.

[0011] In one embodiment, the communication unit is further configured to receive permission revocation indication information sent by the main chain consensus node; wherein, the permission revocation indication information is used to instruct the main chain consensus node to revoke the first consensus node's access permission to the second cross-chain storage space; the permission revocation indication information is generated by the main chain consensus node when it detects that the access permission revocation conditions are met, and the access permission revocation conditions include: the validity period of the access permission has been reached, or the relevant processing of the cross-chain business block has been completed, or the validity period of the access permission has been reached and the relevant processing of the cross-chain business block has been completed.

[0012] On one hand, this application provides another blockchain-based block processing device. The blockchain includes a main business chain, a first business branch chain, and a second business branch chain. The first business branch chain corresponds to a first cross-chain storage space, and the second business branch chain corresponds to a second cross-chain storage space. The main chain consensus node of the main business chain allocates access permissions to the second cross-chain storage space to the first consensus node of the first business branch chain, and allocates access permissions to the first cross-chain storage space to the second consensus node of the second business branch chain. The device includes: A communication unit is used to obtain a cross-chain business block from the first cross-chain storage space; wherein the cross-chain business block is generated and stored in the first cross-chain storage space by the first consensus node for the target business when the target business meets the cross-chain consensus conditions; The processing unit is used to perform cross-chain consensus on the cross-chain business blocks and determine the cross-chain consensus result; The communication unit is further configured to store the cross-chain consensus result in the second cross-chain storage space, so that the first consensus node can obtain the cross-chain consensus result from the second cross-chain storage space and set the status of the cross-chain business block to be submitted to the first business branch chain based on the cross-chain consensus result.

[0013] In one embodiment, the processing unit is further configured to generate a cross-chain consensus block for the cross-chain consensus result, and perform pre-commit processing on the cross-chain consensus block based on the second business branch chain; The communication unit is also used to obtain the status setting result of the cross-chain business block stored by the first consensus node from the first cross-chain storage space; The processing unit is also used to set the status of the cross-chain consensus block to be submitted to the second business branch chain based on the status setting result.

[0014] In one embodiment, when the communication unit stores the cross-chain consensus result to the second cross-chain storage space, it is specifically used to: store the cross-chain consensus block to the second cross-chain storage space; wherein, the first consensus node obtains the cross-chain consensus block from the second cross-chain storage space and extracts the cross-chain consensus result from the cross-chain consensus block.

[0015] In one embodiment, the communication unit is further configured to: Receive a cross-chain consensus request sent by the first consensus node; wherein the cross-chain consensus request carries the block identifier of the cross-chain business block; respond to the cross-chain consensus request and retrieve the cross-chain business block from the first cross-chain storage space based on the block identifier.

[0016] In one embodiment, the communication unit is further configured to receive permission revocation indication information sent by the main chain consensus node; wherein, the permission revocation indication information is used to instruct the main chain consensus node to revoke the second consensus node's access permission to the first cross-chain storage space; the permission revocation indication information is generated by the main chain consensus node when it detects that the access permission revocation conditions are met, and the access permission revocation conditions include: the validity period of the access permission has been reached, or the relevant processing of the cross-chain business block has been completed, or the validity period of the access permission has been reached and the relevant processing of the cross-chain business block has been completed.

[0017] On one hand, embodiments of this application provide a computer device, including: a processor, a communication interface, and a memory, wherein the processor, the communication interface, and the memory are interconnected, wherein the memory stores executable program code, and the processor is used to call the executable program code to implement the blockchain-based block processing method provided in embodiments of this application.

[0018] Accordingly, this application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to implement the blockchain-based block processing method provided in this application.

[0019] Accordingly, this application also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the blockchain-based block processing method provided in this application.

[0020] Accordingly, this application also provides a computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based block processing method provided in this application.

[0021] This application embodiment first pre-submits the cross-chain business block generated by the first consensus node of the first business branch chain to the first business branch chain. Then, the second consensus node of the second business branch chain performs cross-chain consensus on the cross-chain business block. Finally, the first consensus node sets the status of the cross-chain business block pre-submitted to the first business branch chain according to the cross-chain consensus result. This enables cross-chain consensus processing of cross-chain business. On the other hand, different dedicated storage spaces are allocated to different business branch chains for storing cross-chain data. The cross-chain data involved in a certain business branch chain is stored in its dedicated storage space. In this way, the business consensus nodes of other business branch chains that need to process based on the cross-chain data can directly obtain the cross-chain data from the dedicated storage space, which is more efficient than obtaining the cross-chain data directly from the business branch chain. Furthermore, when a business consensus node of a certain business branch chain wants to obtain cross-chain data from the dedicated storage space of other business branch chains, it needs to obtain permission to access the dedicated storage space of other business branch chains first. This can effectively ensure the security of the data stored in the dedicated storage spaces of each business branch chain. Attached Figure Description

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

[0023] Figure 1 This application illustrates a schematic diagram of the structure of a blockchain provided in an exemplary embodiment. Figure 2 This application illustrates a schematic diagram of the structure of a blockchain network provided in an exemplary embodiment. Figure 3 This illustration shows a schematic diagram of a tree-like chain structure provided in an exemplary embodiment of this application; Figure 4 This application illustrates a schematic diagram of the structure of a blockchain network provided in an exemplary embodiment. Figure 5 A flowchart illustrating a cross-chain processing procedure provided in an exemplary embodiment of this application is shown. Figure 6 A schematic flowchart of a blockchain-based block processing method provided in an exemplary embodiment of this application is shown. Figure 7 This illustration shows a schematic diagram of the architecture of a two-layer blockchain network provided in an exemplary embodiment of this application; Figure 8This illustration shows a schematic diagram of the architecture of a two-layer blockchain network provided in an exemplary embodiment of this application; Figure 9 This illustration shows a schematic diagram of the architecture of a two-layer blockchain network provided in an exemplary embodiment of this application; Figure 10 A schematic diagram of the structure of a blockchain-based block processing apparatus provided in an exemplary embodiment of this application is shown; Figure 11 A schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application is shown. Detailed Implementation

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

[0025] This application relates to blockchain, which is the foundation of blockchain technology. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A schematic diagram of a blockchain structure can be found... Figure 1 ,like Figure 1 As shown, Blockchain 101 consists of multiple blocks. The first block of the blockchain is called the genesis block (or simply the genesis block). The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value of the parent block, the version number, the timestamp, and the difficulty value, and so on. This ensures that the block data stored in each block of the blockchain is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0026] A blockchain can be maintained by blockchain nodes contained within a blockchain network; wherein, a blockchain network can be understood as a data sharing system, referring to a system used for data sharing between blockchain nodes, an exemplary structure of which can be found here. Figure 2 ;like Figure 2As shown, the data sharing system may include multiple blockchain nodes 102. Each blockchain node 102 can be a server connected to the blockchain network or a user terminal (such as a client) connected to the blockchain network. The specific form of the blockchain node 102 is not limited here. Each blockchain node 102 in the blockchain network has a corresponding node identifier, and each blockchain node 102 can store the node identifiers of other blockchain nodes 102 in the blockchain network, so that the generated block can be broadcast to other blockchain nodes 102 in the data sharing system based on the node identifiers of other blockchain nodes 102. Each blockchain node 102 can maintain a node identifier list, storing the node name and node identifier in the node identifier list; the node identifier list can be found in Table 1. Table 1

[0027] As shown in Table 1, the node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node; for example, the node identifier can also be a binary sequence code (such as 110001110). Table 1 only uses IP addresses as an example. When a block to be verified is generated in the blockchain network, the blockchain nodes running the consensus mechanism (or consensus nodes) reach a consensus on the block to be verified. After successful consensus, the block to be verified is synchronized to all blockchain nodes in the blockchain network through the node identifier in the node identifier list, realizing distributed storage of data in the blockchain network.

[0028] In practical applications, a blockchain network can maintain more than one blockchain; that is, multiple blockchains can be maintained within a blockchain network. Each blockchain can be used to store business data corresponding to different business types. Taking a tax scenario as an example, the businesses involved in a tax scenario may include: invoice processing, credit investigation, profit and loss reporting, enterprise qualification processing, and tax refund processing, etc. To facilitate better management of business data corresponding to different business types, a separate blockchain can be created for each business type to store the corresponding business data, facilitating the supervision and maintenance of business data for different business types.

[0029] When multiple blockchains are maintained in a blockchain network, they typically form a tree-like chain structure. A tree-like chain can be simply understood as a blockchain structure resembling a tree, formed by a main business chain and one or more branch chains derived from (or forked from) it. A schematic diagram of an exemplary tree-like chain structure can be found here. Figure 3 ,like Figure 3As shown, the tree-like structure includes a main business chain 103 and business branch chains derived from the main business chain 103, such as business branch chain 1031, business branch chain 1032, business branch chain 1033, etc. The main business chain 103 and the business branch chains are briefly introduced below: ① The main business chain 103 may include registration information for various business branch chains. This registration information may include, but is not limited to: the chain identifier of the branch chain, business description information, and the node identifier of the supervisory node. The chain identifier is a unique identifier for the business branch chain, allowing for quick location within the blockchain network. The business description information describes relevant business information corresponding to the branch chain, such as the business type, data format, and verification method. The node identifier of the supervisory node refers to the node identifier of a consensus node that has the authority to supervise the business branch chain (e.g., consensus, storage, etc.). Of course, depending on the actual application scenario, the registration information for business branch chains may include other information besides the above descriptions. This embodiment does not limit the registration information for business branch chains.

[0030] ② A business branch chain is derived from a block height of the main business chain, and its genesis block is located within the main business chain. For example... Figure 3 In this model, the genesis block of business branch chain 1031 is block A1 in the main business chain 103, the genesis block of business branch chain 1032 is block A2 in the main business chain 103, and the genesis block of business branch chain 1033 is block A3 in the main business chain 101. This method of branching from the main business chain to derive business branch chains corresponding to different business types effectively ensures that the main business chain serves as the root of trust for all business branch chains and aggregates global information such as the business configuration of each business branch chain, facilitating subsequent supervision and review.

[0031] The following example, using the derivation of business branch chain 1031 from the main business chain, illustrates the implementation of a derived business branch chain. Specifically, when an event occurs requiring the creation (or derivation) of business branch chain 1031, the smart contract storing the registered business branch chain in the main business chain can be invoked to derive business branch chain 1031. First, a corresponding chain identifier can be generated for business branch chain 1031 based on the business configuration information of the business branch chain to be created (including business description information, node identifiers of other consensus nodes storing the branch chain, etc.), and the corresponding chain identifier for business branch chain 1031 is registered and published in the main business chain. Second, the genesis block "Block A1" of business branch chain 1031 is generated based on the chain identifier, business description information, and node identifiers of the regulatory nodes. Finally, the genesis block "Block A1" is stored in the main business chain, thus realizing the derivation of business branch chain 1031. Once business branch chain 1031 is successfully derived, it can run its own transaction on-chain. For example, when there is a subsequent request to upload business data of the business type corresponding to business branch chain 1031, the block "Block B2" generated based on the business data can be linked to the genesis block "Block A1" to upload the transaction data (or business data) corresponding to its own business type to the chain.

[0032] The following points are worth noting regarding the above description of business branch chains derived from the main business chain: ① If the configuration information in the blockchain network changes, the main business chain and all business branch chains in the blockchain network must upload the changed configuration information to the chain. Only after the main business chain and all business branch chains have successfully uploaded the changed configuration information to the chain will the main business chain and each business branch chain execute their respective on-chain logic. For example, the main business chain will then execute the derivation of business branch chains, and the business branch chains will then execute the data uploading. The configuration information in the blockchain network varies in different application scenarios. For example, in a tax scenario, the configuration information may include, but is not limited to, regulatory rules in the tax field, changes in computing regulations, changes in important blockchain nodes, and rotation of certificate issuing nodes. This application embodiment does not limit the specific content of the configuration information in the blockchain network.

[0033] See also Figure 3Assuming the latest block height of the current main business chain 103 is the block height corresponding to "block A2", the latest block height of business branch chain 1031 is the block height corresponding to "block B4", and the latest block height of business branch chain 1032 is the block height corresponding to "block C4", then in response to changes in the blockchain network configuration information, the operation logic of the main business chain 103 and each business branch chain (such as the derivation logic of business branch chains from the main business chain, or the on-chain logic of data in business branch chains) is suspended. Instead, a new block is generated based on the changed configuration information, and this new block is synchronized to the main business chain and the business branch chain. Business branch chain 1031 and business branch chain 1032, for example, after a new block is synchronized to the main business chain 103, the latest block height of the main business chain 103 is updated to "block A3", the latest block height of the business branch chain 1031 is updated to the block height corresponding to "block B5", and the latest block height of the business branch chain 1032 is updated to the block height corresponding to "block C5". After the main business chain and all business branch chains have successfully produced blocks, the main business chain and each business branch chain will continue to execute their respective transactions on the chain, such as the main business chain creating a new business branch chain 1033, or the business branch chain 1032 adding "block C6".

[0034] ②The preceding section mainly introduced the main business chain and business branch chains included in the blockchain network. The following section will combine... Figure 4 This section provides a brief overview of the nodes in the main chain and branch chains of the storage business within a blockchain network. For example... Figure 4As shown, a blockchain network can include multiple consensus clusters, and each consensus cluster can include one or more consensus nodes for maintaining the chain within its cluster. To distinguish between consensus clusters that maintain the main business chain and business branch chains, this application embodiment divides the consensus clusters in the blockchain network into: main chain consensus clusters and branch chain consensus clusters. The main chain consensus cluster contains one or more main chain consensus nodes for maintaining the main business chain. Each main chain consensus node is a consensus node with supervisory authority over the main business chain. Supervisory authority over the main business chain can refer to the authority to operate on the main business chain, such as deriving a business branch chain from it. The branch chain consensus cluster contains one or more business consensus nodes for maintaining the business branch chains within its cluster. Each business consensus node is a consensus node with supervisory authority over the business branch chains, such as business consensus node 1 having supervisory authority over business branch chain 1031, and business consensus node 2 having supervisory authority over business branch chain 1032. Supervisory authority over business branch chains can refer to the authority to reach consensus on unverified blocks to be stored in the business branch chain, etc. It should be noted that the main chain consensus node can also maintain all or part of the business branch chain. This application embodiment does not limit this. In addition to maintaining the business branch chain within its own cluster, each business consensus node also synchronizes the business main chain, but does not have the authority to supervise the business main chain.

[0035] The following example illustrates how nodes in the main chain and branch chains of a blockchain network store business data, using a tax scenario as an example. Assuming the tax scenario involves invoice and credit reporting, and the tax regulator has oversight authority over all tax-related matters, the device used by the tax regulator can connect to the main chain consensus cluster in the blockchain network. For instance, the device used by the tax regulator can act as a main chain consensus node within the main chain consensus cluster. Similarly, the device used by the invoice regulator with oversight authority over invoice-related matters can connect to the branch chain consensus cluster "Invoice Consensus Cluster," and the device used by the credit regulator with oversight authority over credit reporting matters can connect to the branch chain consensus cluster "Credit Reporting Consensus Cluster." This tree-like chain structure allows for the separate storage and oversight of various business types within a tax scenario, effectively distinguishing business data across different business types, maintaining the exclusivity of business data in each branch chain, improving the efficiency of business data oversight, and facilitating data maintenance.

[0036] ③ When a block to be verified is generated in any consensus cluster of the blockchain network, the consensus node in that consensus cluster can reach a consensus on the block to be verified. This allows different consensus clusters to execute consensus on the blocks to be verified within their respective clusters in parallel, improving consensus efficiency. Furthermore, when any consensus cluster reaches a consensus on a block to be verified generated within its own cluster, in addition to verifying the business branch chains contained within that cluster, it can also locate the main business chain based on the genesis block of the business branch chain within the main business chain, and verify all blocks within the block height range from the genesis block of the business branch chain to the genesis block of the main business chain. This improves the rigor of block verification and ensures the security of business data stored on the chain. Of course, if all historical blocks in the business branch chain have been successfully verified, this application embodiment also supports consensus only on new blocks to be verified, which is hereby stated.

[0037] In practical applications, when a blockchain network maintains the tree-like chain structure described above, there is often a need for cross-chain processing. This includes situations where cross-chain consensus is required for a specific type of business, which is called a cross-chain business. For example, in a tax scenario, there might be a need for cross-chain consensus. Suppose that the blockchain network corresponding to the tax scenario maintains a first business branch chain for invoice processing and a second business branch chain for credit reporting. Suppose that issuing an invoice to a target user (such as any user with an invoice request) requires consensus (or verification) on the target user's credit information. Only after the credit consensus is passed will the invoice issued to the target user become effective. In response to the target user's invoice request, the invoice is first issued to the target user on the first business branch chain. At this point, although the invoice has been issued, it is not yet effective and cannot be used normally. The second business branch chain needs to reach a consensus on the target user's credit information. Only when the second business branch chain confirms that the target user's credit consensus has passed will the first business branch chain set the invoice issued to the target user to an effective state. Only effective invoices can be used normally.

[0038] In the aforementioned cross-chain consensus process, cross-chain data acquisition involves several steps, including: before the second business branch chain reaches consensus on the target user's credit information, it is necessary to obtain relevant information about the target user from the first business branch chain to achieve consensus on the target user's credit data; additionally, before the first business branch chain sets the invoice issued to the target user to an effective status, it is necessary to obtain the consensus result on the target user's credit information from the second business branch chain, and so on. To acquire cross-chain data, the blockchain hosting the cross-chain data can be monitored, and the required cross-chain data can be directly obtained from that blockchain. However, this method is complex to implement, requires extensive data interaction between blockchains, and is time-consuming and inefficient.

[0039] To achieve cross-chain consensus and improve the efficiency of acquiring cross-chain data in cross-chain consensus, this application proposes a block processing method based on the tree-structured chain described above. The first and second business branch chains involved in this block processing method can refer to two different business branch chains derived from the main business chain. The processing flow of this block processing method can be found in [reference needed]. Figure 5 ,like Figure 5 As shown: Suppose that business branch chain 1031 (i.e., the first business branch chain) needs to refer to the consensus result (or verification result) of business branch chain 1032 (i.e., the second business branch chain) regarding all or part of the features involved in the business for processing its business. That is, there will be cross-chain interaction between business branch chain 1031 and business branch chain 1032, and cross-chain interaction necessarily involves the process of obtaining cross-chain data. At this time, business branch chain 1031 (specifically, the business consensus node of business branch chain 1031, such as the first consensus node) needs to request the allocation (or registration) of cross-chain storage space specifically for storing the cross-chain data involved in business branch chain 1031 from business main chain 103 (specifically, the main chain consensus node of business main chain 103). Similarly, business branch chain 1032 (specifically, the business consensus node of business branch chain 1032, such as the second consensus node) also needs to request the allocation of cross-chain storage space specifically for storing the cross-chain data involved in business branch chain 1032 from business main chain 103.

[0040] In response to a request from business branch chain 1031, main chain 103 allocates a dedicated cross-chain storage space B (i.e., the first cross-chain storage space) to business branch chain 1031. This dedicated cross-chain storage space B is attached to the business consensus node of business branch chain 1031, and the business consensus node of business branch chain 1031 has permanent usage rights to this dedicated cross-chain storage space B. Consensus nodes of other chains need to obtain access rights before they can access this dedicated cross-chain storage space B. In response to a request from business branch chain 1032, main chain 103 allocates a dedicated cross-chain storage space C (i.e., the second cross-chain storage space) to business branch chain 1032. This dedicated cross-chain storage space C is attached to the business consensus node of business branch chain 1032, and the business consensus node of business branch chain 1032 has permanent usage rights to this dedicated cross-chain storage space C. Consensus nodes of other chains need to obtain access rights before they can access this dedicated cross-chain storage space C. Dedicated cross-chain storage spaces B and C are different.

[0041] In a feasible embodiment, business branch chain 1031 may request the business main chain 103 to allocate cross-chain storage space specifically for storing cross-chain data involved in business branch chain 1031, and also request the allocation of cross-chain storage space specifically for storing cross-chain data involved in business branch chain 1032. The business main chain 103 responds to the requests from business branch chain 1031 by allocating dedicated cross-chain storage space B for business branch chain 1031 and dedicated cross-chain storage space C for business branch chain 1032. This way, only business branch chain 1031 needs to send a request to the business main chain 103, without requiring business branch chain 1032 to send a request to the business main chain 103, resulting in higher efficiency.

[0042] The aforementioned cross-chain storage space can be cloud storage space, similar to a cloud drive. The form of this cross-chain storage space can be a mountable cross-chain monitoring storage component (ECFS, elastic cross-chain file system).

[0043] It should be noted that business branch chain 1031 and / or business branch chain 1032 may request cross-chain storage space from business main chain 103 immediately after the business branch chain initialization (or construction) is completed, or they may request cross-chain storage space from business main chain 103 only when cross-chain business or cross-chain processing is involved.

[0044] After receiving their allocated cross-chain storage space, and once business branch chains 1031 and 1032 begin their respective business processes, they need to write the relevant cross-chain business blocks (including blocks generated for businesses requiring cross-chain consensus, blocks generated from the cross-chain consensus results of cross-chain businesses, etc.) and the validity proofs of the cross-chain business blocks into their respective registered cross-chain storage space (ECFS). This validity proof includes: indications indicating the legality of the relevant data in the cross-chain business block, indications indicating that the initial consensus of the cross-chain business block has passed, etc. Each business branch chain needs to maintain its cross-chain storage space at a height that is substantially consistent with the latest block height on its own chain; that is, it needs to promptly upload the relevant cross-chain business blocks from its own chain to its own cross-chain storage space. The main business chain 103 can read and randomly check each business branch chain (including business branch chains 1031 and 1032, etc.) and the cross-chain storage space of each business branch chain. If the comparison shows that the cross-chain storage space of business branch chain 1031 is not effectively maintained, such as: failing to upload cross-chain business-related blocks to its own cross-chain storage space for a set period of time, or failing to upload cross-chain business-related blocks to its own cross-chain storage space more than a set number of times; the main business chain can revoke the right of business branch chain 1031 to use cross-chain storage space B. At this time, business branch chain 1031 and other business branch chains will not be able to access cross-chain storage space B.

[0045] Assuming each business branch chain correctly maintains its own cross-chain storage space, before or during cross-chain consensus, business branch chain 1031 requests access to cross-chain storage space C (the cross-chain storage space of business branch chain 1032) from business main chain 103, while business branch chain 1032 requests access to cross-chain storage space B (the cross-chain storage space of business branch chain 1031) from business main chain 103. After successful access requests, the business consensus node of business branch chain 1031 has limited-time permission to mount cross-chain storage space C. After mounting cross-chain storage space C, business branch chain 1031 can monitor the cross-chain data and data status of business branch chain 1032 through cross-chain storage space C. It should be noted that cross-chain storage space C is only readable by business branch chain 1031. Similarly, after the access permission application is successful, the business consensus node of business branch chain 1032 will have limited permission to mount cross-chain storage space B. After mounting cross-chain storage space B, business branch chain 1032 can monitor the cross-chain data and data status of business branch chain 1031 through cross-chain storage space B. It should be noted that cross-chain storage space B is only readable by business branch chain 1032.

[0046] During cross-chain consensus processing, business branch chain 1031 generates a cross-chain business block X for the cross-chain business (i.e., the target business that meets the cross-chain consensus conditions) and pre-submits cross-chain business block X to business branch chain 1031. Pre-submission means storing the cross-chain business block on the blockchain first, but its status is pending; it may be valid or invalid and needs to be set later. Business branch chain 1031 also stores cross-chain business block X in cross-chain storage space B. Business branch chain 1032 retrieves cross-chain business block X from cross-chain storage space B and performs cross-chain consensus on cross-chain business block X to obtain the cross-chain consensus result. Business branch chain 1032 generates a cross-chain consensus block Y based on the cross-chain consensus result, pre-submits cross-chain consensus block Y to business branch chain 1032, and stores cross-chain consensus block Y in cross-chain storage space C. Business branch chain 1031 obtains cross-chain consensus block Y from cross-chain storage space C, and obtains the cross-chain consensus result of cross-chain business block X from cross-chain consensus block Y.

[0047] If the cross-chain consensus for cross-chain business block X is determined to have passed, based on the cross-chain consensus result, the state of cross-chain business block X pre-submitted to business branch chain 1031 is set to a valid state. This can be achieved by adding a first state declaration block to the end of cross-chain business block X on business branch chain 1031 to declare the state of cross-chain business block X. This first state declaration block is used to declare that cross-chain business block X on business branch chain 1031 is valid. If the cross-chain consensus for cross-chain business block X is determined to have failed, the state of cross-chain business block X pre-submitted to business branch chain 1031 is set to an invalid state. This can be achieved by adding a second state declaration block to the end of cross-chain business block X on business branch chain 1031 to declare the state of cross-chain business block X. This second state declaration block is used to declare that cross-chain business block X on business branch chain 1031 is invalid.

[0048] Furthermore, business branch chain 1031 stores the state declaration block of cross-chain business block X in cross-chain storage space B. Business branch chain 1032 retrieves the state declaration block of cross-chain business block X from cross-chain storage space B. When the state of cross-chain business block X declared by the state declaration block matches the cross-chain consensus result, the state of cross-chain consensus block Y pre-submitted to business branch chain 1032 is set to a valid state. This means that business branch chain 1031 sets the state of cross-chain business block X pre-submitted to business branch chain 1031 based on the cross-chain consensus result of business branch chain 1032 for cross-chain business block X. Similarly, a third state declaration block can be added after cross-chain consensus block Y on business branch chain 1032 to declare the state of cross-chain consensus block Y. This third state declaration block is used to declare that cross-chain consensus block Y on business branch chain 1032 is valid. The matching includes: the cross-chain consensus result indicates that the cross-chain consensus of cross-chain business block X failed, and the state of cross-chain business block X declared by the state declaration block is invalid; or, the cross-chain consensus result indicates that the cross-chain consensus of cross-chain business block X passed, and the state of cross-chain business block X declared by the state declaration block is valid.

[0049] When the state of cross-chain business block X declared by the state declaration block does not match the cross-chain consensus result, the state of cross-chain consensus block Y pre-submitted to business branch chain 1032 is set to invalid. This means that business branch chain 1031 did not set the state of cross-chain business block X pre-submitted to business branch chain 1031 based on the cross-chain consensus result of business branch chain 1032 for cross-chain business block X. Similarly, a fourth state declaration block can be added after cross-chain consensus block Y on business branch chain 1032 to declare the state of cross-chain consensus block Y invalid. Among them, mismatch includes: the cross-chain consensus result indicates that the cross-chain business block X failed to pass the cross-chain consensus, while the state of the cross-chain business block X declared by the state declaration block is a valid state; or, the cross-chain consensus result indicates that the cross-chain business block X passed the cross-chain consensus, while the state of the cross-chain business block X declared by the state declaration block is an invalid state.

[0050] This situation may be caused by a discrepancy between the cross-chain consensus result of business branch chain 1032 on cross-chain business block X obtained by business branch chain 1031 and the actual cross-chain consensus result of business branch chain 1032 on cross-chain business block X. This discrepancy may be due to malicious tampering with the cross-chain consensus result of cross-chain business block X stored in the cross-chain storage space C. To address this, the main business chain can reset the state of cross-chain business block X pre-submitted to business branch chain 1031 based on the actual cross-chain consensus result of business branch chain 1032 when it detects that the state of cross-chain consensus block Y on business branch chain 1032 is invalid.

[0051] Furthermore, business branch chain 1032 will store the state declaration block of cross-chain consensus block Y in cross-chain storage space C. At this point, business branch chain 1032 has completed the relevant processing of cross-chain business. If business branch chain 1031 obtains the state declaration block of cross-chain consensus block Y from cross-chain storage space C, it can also be determined that the relevant processing of cross-chain business has been completed. After detecting that the relevant processing of cross-chain business is completed, or after detecting that the valid time of access permission has been reached, the main business chain can revoke the access permission of business branch chain 1031 to cross-chain storage space C (or business branch chain 1031 can actively relinquish its access permission to cross-chain storage space C, and subsequent access will require a new application), and / or, the main business chain can revoke the access permission of business branch chain 1032 to cross-chain storage space B (or business branch chain 1032 can actively relinquish its access permission to cross-chain storage space B, and subsequent access will require a new application). It should be noted that if the effective time for business branch chain 1031 to have access to cross-chain storage space C, or the effective time for business branch chain 1032 to have access to cross-chain storage space B, is reached before the relevant processing of cross-chain business is completed, then business branch chain 1031 or 1032 can reapply (or apply for renewal) to the main business chain 103 for access to the corresponding cross-chain storage space.

[0052] It should be noted that, for ease of description and understanding, the above description of the cross-chain consensus process is based on the blockchain (including the main business chain and business branch chains) as the executing entity. It can be understood that, in the actual process, the main chain consensus node of the main business chain may execute the above processing steps of the main business chain, or the business consensus node of the business branch chain may execute the above processing steps of the business branch chain.

[0053] This application's embodiments, based on the block processing method provided by the tree-structured blockchain, propose a method for acquiring cross-chain data by combining a mountable cross-chain monitoring storage component (ECFS). This enables high-speed access to cross-chain data during the processing of cross-chain business, significantly improving data acquisition efficiency compared to directly obtaining cross-chain data from the blockchain. This method leverages the remote mounting and removal capabilities of network storage components to implement a flexible message monitoring mechanism for cross-chain operations. Furthermore, by registering ECFS with the main chain and allocating its validity period, the security and access control of ECFS can be effectively guaranteed. In addition, the emergence of ECFS eliminates the need for business branch chains to actively monitor the target chain during cross-chain operations, greatly reducing redundant data. Moreover, when cross-chain processing begins, it can be mounted and verified immediately, eliminating the difficulty of synchronous verification in height order. After cross-chain processing is completed, the target chain data can also be quickly decoupled from the main chain, achieving secure isolation and protection of information.

[0054] Based on the cross-chain consensus scheme described above, this application proposes a more detailed cross-chain consensus method. The cross-chain consensus method proposed in this application will be described in detail below with reference to the accompanying drawings.

[0055] Please see Figure 6 This is a flowchart illustrating a blockchain-based block processing method provided in an embodiment of this application. This blockchain-based block processing method can be applied to the tree-structured blockchain described above, and can be determined by main chain consensus nodes (such as...). Figure 4 The main chain consensus nodes in the main chain consensus cluster shown), and the first consensus node (such as...) Figure 4 The business consensus node 1 and the second consensus node (as shown) are shown. Figure 4 The business consensus node 2 shown is jointly executed, and this main chain consensus node can be the business main chain in a tree-structured chain (such as...). Figure 4 The first consensus node can be any one of all consensus nodes corresponding to the main business chain 103 shown, and this first consensus node can be the first business branch chain in the tree structure chain (such as...). Figure 4 The second consensus node can be any one of all business consensus nodes corresponding to the business branch chain 1031 shown; the second consensus node can be the second business branch chain in the tree structure chain (such as...). Figure 4 This refers to any one of the business consensus nodes corresponding to the business branch chain 1032 shown. The following description uses the example of the first business branch chain processing its cross-chain business, which requires reference to the consensus result (or verification result) of the business consensus node of the second business branch chain regarding all or part of the features involved in the cross-chain business, to illustrate the blockchain-based block processing method provided in this application embodiment. This blockchain-based block processing method includes, but is not limited to, the following steps: S601, the first consensus node obtains the target service.

[0056] In this embodiment, the target business can be a business that the business consensus node of the first business branch chain can handle, which can be understood as a transaction, such as an invoice transaction in a tax scenario. The first consensus node can be the master node elected by all business consensus nodes of the first business branch chain at the current stage, and the elected master node processes the target business. The so-called master node refers to the consensus node responsible for producing blocks (i.e., generating blocks) at the current stage. The business consensus nodes of the first business branch chain other than the first consensus node are the slave nodes at the current stage, and the slave nodes are responsible for reaching consensus on the blocks generated by the master node at the current stage. The current stage can refer to the current block height.

[0057] After the first consensus node obtains the target business, it determines whether the target business meets the cross-chain consensus conditions. In one embodiment, if the established consensus rules indicate that the processing of businesses involved in the first business branch chain requires reference to the consensus results (or verification results) of business consensus nodes of other business branch chains regarding all or part of the features involved in the business, then the target business is determined to meet the cross-chain consensus conditions. Alternatively, if the established consensus rules indicate that the processing of businesses of the business type to which the target business belongs by the first business branch chain requires reference to the consensus results of business consensus nodes of other business branch chains regarding all or part of the features involved in the business type, then the target business is determined to meet the cross-chain consensus conditions. Otherwise, the target business is determined not to meet the cross-chain consensus conditions.

[0058] For example, in a tax scenario, the blockchain network corresponding to the tax scenario maintains a first business branch chain for invoice business and a second business branch chain for credit investigation business. The target business is issuing invoices. If issuing invoices requires consensus not only from the business consensus nodes of the first business branch chain on the data involved in the invoice (such as invoice amount, invoice time, company name, NARUI ID number, etc.), but also from the second business branch chain on the credit investigation of the invoice recipient (such as user A), then the business of issuing invoices is a cross-chain business and requires cross-chain consensus.

[0059] If the target business meets the cross-chain consensus conditions, it indicates that the target business is a cross-chain business and requires cross-chain consensus processing. In this case, steps S202-S208 are executed. If the target business does not meet the cross-chain consensus conditions, it indicates that the target business is a normal business and does not require cross-chain consensus processing. In this case, a business block to be added to the chain is generated for the target business, and all business consensus nodes of the first business branch chain are triggered to reach a consensus on the business block to be added to the chain. If the consensus on the business block to be added to the chain passes, the business block to be added to the chain is added to the first business branch chain.

[0060] S602. If the target business meets the cross-chain consensus conditions, the first consensus node will generate a cross-chain business block for the target business.

[0061] In feasible embodiments, cross-chain business blocks can be like ordinary blocks, including a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value of the parent block, the version number, the timestamp, and the difficulty value. The block body stores the input information, which is related to the target business. In feasible embodiments, cross-chain business blocks can have certain differences from ordinary blocks, including one or more of the following: adding a cross-chain identifier to the cross-chain business block, which indicates that the block is a cross-chain block and requires cross-chain consensus processing; adding a target blockchain identifier to the cross-chain business block, which includes the identifier of the blockchain that needs to perform cross-chain consensus on the cross-chain business block. When the business consensus nodes that need to perform cross-chain consensus on the cross-chain business block include a second business branch chain, the identifier of the second business branch chain can be determined as the target blockchain identifier.

[0062] S603, the first consensus node performs pre-commit processing on cross-chain business blocks based on the first business branch chain, and stores the cross-chain business blocks in the first cross-chain storage space.

[0063] In this embodiment of the application, the pre-commit processing of cross-chain business blocks by the first consensus node based on the first business branch chain includes: pre-committing the cross-chain business blocks to the first business branch chain. Pre-committing means adding the generated block to the blockchain first, but the state of the block is pending, that is, the block added to the blockchain may be valid or invalid, and needs to be set later.

[0064] The first cross-chain storage space is a dedicated storage space allocated by the main chain consensus node (which can be any consensus node in the main chain or a consensus node with cross-chain storage space allocation authority among all consensus nodes in the main chain) to all business consensus nodes (including the first consensus node) of the first business branch chain. This space is specifically used to store cross-chain data involved in the first business branch chain. Consensus nodes of other chains need to obtain access permissions before accessing this first cross-chain storage space. This first cross-chain storage space can be allocated immediately after the initialization (or creation) of the first business branch chain by the business consensus node of the first business branch chain, upon request from the main chain consensus node; or it can be allocated only when cross-chain business processing is involved. The first consensus node can store the cross-chain business block in the first cross-chain storage space after pre-submitting it to the first business branch chain; or it can store the cross-chain business block in the first cross-chain storage space simultaneously with pre-submitting it to the first business branch chain.

[0065] In one feasible embodiment, the first cross-chain storage space contains one or more data storage blockchains, each corresponding to a business branch chain that has a cross-chain consensus relationship with the first business branch chain. The data storage blockchain can be a special type of blockchain where adjacent blocks do not have a parent-child relationship, or the blocks are independent of each other and added to the blockchain in chronological order. When a business consensus node, including the second business branch chain, needs to perform cross-chain consensus on a cross-chain business block, the first consensus node can store the cross-chain business block on the data storage blockchain corresponding to the second business branch chain in the first cross-chain storage space. In another feasible embodiment, the first cross-chain storage space is divided into one or more sub-storage spaces, each corresponding to a business branch chain that has a cross-chain consensus relationship with the first business branch chain. When a business consensus node, including the second business branch chain, needs to perform cross-chain consensus on a cross-chain business block, the first consensus node can store the cross-chain business block in the sub-storage space corresponding to the second business branch chain in the first cross-chain storage space. By adopting the above storage method, the business consensus nodes of the second business branch chain can quickly obtain the cross-chain business block (i.e., cross-chain data) that needs to be processed for cross-chain consensus from the first cross-chain storage space.

[0066] In a feasible implementation, after generating a cross-chain business block, the first consensus node can trigger all business consensus nodes of the first business branch chain to conduct initial consensus on the cross-chain business block. If the initial consensus result indicates that the cross-chain business block consensus has passed, then the cross-chain business block is pre-committed based on the first business branch chain, and the cross-chain business block is stored in the first cross-chain storage space. The initial consensus on the cross-chain business block can involve reaching consensus on relevant information of the target business within the cross-chain business block. For example, in a tax scenario, if the first business branch chain is the blockchain maintaining the invoice business in the blockchain network corresponding to the tax scenario, and the target business is issuing invoices, then the initial consensus on the cross-chain business block by all business consensus nodes of the first business branch chain can involve reaching consensus on invoice-related data (such as invoice amount, invoice time, company name, NARIN ID number, etc.).

[0067] S604, the second consensus node obtains the cross-chain business block from the first cross-chain storage space.

[0068] In this embodiment, the second consensus node can be any business consensus node in the second business branch chain, or it can be the master node elected by all business consensus nodes in the second business branch chain at the current stage. The master node refers to the consensus node responsible for producing blocks (i.e., generating blocks) at the current stage. The business consensus nodes in the second business branch chain other than the second consensus node are the slave nodes at the current stage, and the slave nodes are responsible for reaching consensus on the blocks generated by the master node at the current stage. The current stage can refer to the current block height.

[0069] Before a second consensus node can retrieve a cross-chain business block from the first cross-chain storage space, it needs to acquire access permissions to that storage space. The second consensus node sends an access permission request for the first cross-chain storage space to the main chain consensus node of the main business chain, so that the main chain consensus node responds to the request and allocates access permissions to the second consensus node for the first cross-chain storage space. The second consensus node can request access permissions to the first cross-chain storage space immediately after the main chain consensus node has allocated the first cross-chain storage space to the business consensus node of the first business branch chain; alternatively, the second consensus node can request access permissions only when cross-chain business processing is involved. After acquiring access permissions, the second consensus node retrieves the cross-chain business block from the first cross-chain storage space. It should be noted that the first cross-chain storage space is only readable by the second consensus node.

[0070] In one embodiment, a first consensus node determines a consensus node for cross-chain consensus on a target business. If the consensus node for cross-chain consensus on the target business includes a business consensus node on a second business branch chain, the first consensus node broadcasts a cross-chain consensus request to the business consensus node on the second business branch chain. This cross-chain consensus request may carry a block identifier for the cross-chain business block. After receiving the cross-chain consensus request from the first consensus node, if the second consensus node has already obtained access to the first cross-chain storage space, the second consensus node can immediately retrieve the cross-chain business block from the first cross-chain storage space based on the block identifier. This can be done by retrieving the cross-chain business block from the blockchain or sub-storage space corresponding to the second business branch chain within the first cross-chain storage space. If the second consensus node has not yet obtained access to the first cross-chain storage space, the second consensus node responds to the cross-chain consensus request by sending an access permission request for the first cross-chain storage space to the main chain consensus node. After obtaining access permission, the second consensus node retrieves the cross-chain business block from the first cross-chain storage space based on the block identifier. This can be done by retrieving the cross-chain business block from the blockchain or sub-storage space corresponding to the second business branch chain within the first cross-chain storage space. Optionally, the cross-chain consensus request may also carry the address information of the first cross-chain storage space for storing cross-chain business blocks.

[0071] S605, the second consensus node performs cross-chain consensus on the cross-chain business block and determines the cross-chain consensus result of the cross-chain business block.

[0072] In one embodiment, after the second consensus node obtains the cross-chain business block, it acquires feature data of specific characteristics related to the target business within the cross-chain business block. This specific characteristic is related to the business corresponding to the second business branch chain. For example, if the second business branch chain is the blockchain maintaining the credit reporting business in the blockchain network corresponding to the tax scenario, and the target business is invoicing, then the specific characteristic could be the credit reporting of the invoicing object. Based on this feature data, the verification result of the specific characteristic is determined. This verification result indicates whether the verification passed or failed. Then, the cross-chain consensus result of the cross-chain business block can be directly determined based on the verification result. If the verification result indicates that the verification passed, a cross-chain consensus result indicating that the cross-chain consensus of the cross-chain business block passed is generated; if the verification result indicates that the verification failed, a cross-chain consensus result indicating that the cross-chain consensus of the cross-chain business block failed is generated.

[0073] In another embodiment, after the second consensus node obtains the cross-chain business block, it acquires the specific characteristics involved in the target business within the cross-chain business block and broadcasts these specific characteristics to all business consensus nodes of the second business branch chain. Each business consensus node of the second business branch chain determines the verification result of the specific characteristic based on its characteristic data and returns the verification result to the second consensus node. The second consensus node counts the verification results returned by each business consensus node. If the verification results of more than a set proportion (e.g., 2 / 3) of the business consensus nodes indicate that the verification has passed, a cross-chain consensus result indicating that the cross-chain consensus of the cross-chain business block has passed is generated based on the count. Conversely, if the verification results of more than a set proportion of the business consensus nodes indicate that the verification has failed, a cross-chain consensus result indicating that the cross-chain consensus of the cross-chain business block has failed is generated based on the count.

[0074] For example, in a tax scenario, the first business branch chain is the blockchain maintaining the invoice business within the blockchain network corresponding to the tax scenario, and the second business branch chain is the blockchain maintaining the credit reporting business within the same blockchain network. The target business is issuing invoices. The business consensus nodes of the first business branch chain perform initial consensus on this cross-chain business block, which could be based on invoice-related data (e.g., invoice amount, invoice date, company name, NARIE ID number, etc.). Meanwhile, the business consensus nodes of the second business branch chain perform cross-chain consensus on this cross-chain business block, which could be based on consensus on the credit reporting of the invoice recipient (e.g., user A). In this case, the specific characteristics mentioned above can be the credit reporting of the invoice recipient, and the feature data of these specific characteristics can be the historical credit reporting data of the invoice recipient. If, based on the historical credit reporting data of the invoice recipient, it is determined that the invoice recipient has good credit and no adverse (e.g., criminal) records, then the credit reporting verification of the invoice recipient is deemed successful; otherwise, the credit reporting verification of the invoice recipient is deemed unsuccessful.

[0075] S606, the second consensus node stores the cross-chain consensus result of the cross-chain business block into the second cross-chain storage space.

[0076] In this embodiment, the second cross-chain storage space is a dedicated storage space allocated by the main chain consensus node of the main business chain (which can be any consensus node of the main business chain or a consensus node among all consensus nodes of the main business chain that has the authority to allocate cross-chain storage space) to all business consensus nodes (including the second consensus node) of the second business branch chain. Consensus nodes of other chains need to obtain access permissions before they can access this second cross-chain storage space. The first cross-chain storage space can be allocated immediately after the initialization of the second business branch chain (i.e., after the creation of the second business branch chain) is completed, by the business consensus node of the second business branch chain requesting allocation from the main chain consensus node of the main business chain; or it can be allocated only when cross-chain business processing is involved, by the business consensus node of the second business branch chain requesting allocation from the main chain consensus node of the main business chain. In other feasible embodiments, when the business consensus node of the first business branch chain requests the main chain consensus node of the business main chain to allocate cross-chain storage space corresponding to the first business branch chain, the business consensus node of the first business branch chain may also request the main chain consensus node of the business main chain to allocate cross-chain storage space corresponding to the second business branch chain.

[0077] In this embodiment, the second consensus node can directly store the cross-chain consensus result of the cross-chain business block in the second cross-chain storage space. The cross-chain consensus result can carry a target identifier, which indicates that the cross-chain consensus result is the cross-chain consensus result of the aforementioned cross-chain business block. Alternatively, the second consensus node can generate a cross-chain consensus block based on the cross-chain consensus result and store it in the second cross-chain storage space. This cross-chain consensus block can also carry a target identifier, which indicates that the cross-chain consensus block carries the cross-chain consensus result of the aforementioned cross-chain business block. In a feasible embodiment, the second cross-chain storage space contains one or more data storage blockchains. Each blockchain corresponds to a business branch chain that has a cross-chain consensus relationship with the second business branch chain. In this case, the second consensus node can store the cross-chain consensus block on the data storage blockchain corresponding to the first business branch chain in the second cross-chain storage space. In another feasible embodiment, the second cross-chain storage space is divided into one or more sub-storage spaces, each sub-storage space corresponding to a business branch chain that has a cross-chain consensus relationship with the first business branch chain. The second consensus node can then store the cross-chain consensus block or cross-chain consensus result in the sub-storage space corresponding to the first business branch chain within the second cross-chain storage space. Using this storage method, the business consensus node of the first business branch chain can quickly obtain the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space.

[0078] S607. The first consensus node obtains the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space.

[0079] In this embodiment, before the first consensus node retrieves the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space, it needs to obtain access permissions to the second cross-chain storage space. The first consensus node sends an access permission request for the second cross-chain storage space to the main chain consensus node of the main business chain, so that the main chain consensus node responds to the access permission request and allocates access permissions to the second cross-chain storage space to the first consensus node. After obtaining access permissions to the second cross-chain storage space, the first consensus node retrieves the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space. It should be noted that the second cross-chain storage space is only readable by the first consensus node.

[0080] In one embodiment, the first consensus node may request access to the second cross-chain storage space from the main chain consensus node immediately after the main chain consensus node has allocated the second cross-chain storage space to the business consensus node of the second business branch chain. Alternatively, the first consensus node may request access to the second cross-chain storage space from the main chain consensus node only when processing cross-chain business is involved. In feasible implementations, the first consensus node determines the consensus node that performs cross-chain consensus for the target business; if the consensus node performing cross-chain consensus for the target business includes the business consensus node of the second business branch chain, then it immediately requests access to the second cross-chain storage space from the main chain consensus node.

[0081] In one embodiment, after the first consensus node obtains access to the second cross-chain storage space, it can query the second cross-chain storage space at preset time intervals to obtain the cross-chain consensus results of the cross-chain business blocks from the second cross-chain storage space. In another embodiment, after the second consensus node stores the cross-chain consensus results of the cross-chain business blocks in the second cross-chain storage space, it can send an indication message to the consensus nodes of the first business branch chain (or only to the first consensus node) to indicate that the cross-chain consensus results have been uploaded. After receiving the indication message, and having obtained access to the second cross-chain storage space, the second consensus node obtains the cross-chain consensus results of the cross-chain business blocks from the second cross-chain storage space. This can greatly reduce the number of times the first consensus node makes invalid accesses to the second cross-chain storage space, save hardware and software resources, and avoid access congestion caused by excessive access to the second cross-chain storage space.

[0082] In a feasible implementation, the first consensus node may request access to the second cross-chain storage space from the main chain consensus node only after receiving the instruction information. Furthermore, when the second consensus node stores the aforementioned cross-chain consensus block in the second cross-chain storage space, the first consensus node retrieves the cross-chain consensus block from the second cross-chain storage space and extracts the cross-chain consensus result of the cross-chain business block from it. The first consensus node may retrieve the cross-chain consensus block from the data storage blockchain or sub-storage space corresponding to the first business branch chain in the second cross-chain storage space.

[0083] S608. The first consensus node sets the status of the cross-chain business blocks to be submitted to the first business branch chain based on the cross-chain consensus result.

[0084] In this embodiment, if the cross-chain consensus result indicates that the cross-chain business block has passed cross-chain consensus, the status of the cross-chain business block pre-submitted to the first business branch chain is set to a valid state. This can be achieved by adding a first state declaration block to the end of the cross-chain business block on the first business branch chain to declare the cross-chain business block as valid. At this time, the cross-chain business block is effective and can be used normally. If the cross-chain consensus result indicates that the cross-chain business block has failed cross-chain consensus, the status of the cross-chain business block pre-submitted to the first business branch chain is set to an invalid state. This can be achieved by adding a second state declaration block to the end of the cross-chain business block on the first business branch chain to declare the cross-chain business block as invalid. At this time, the cross-chain business block is invalid and cannot be used normally. In feasible embodiments, setting the status of the cross-chain business block pre-submitted to the first business branch chain to an invalid state can also be achieved by deleting the cross-chain business block from the first business branch chain.

[0085] In feasible embodiments, the blockchain-based block processing method provided in this application, in addition to the steps S601-S608 described above, may also include the following steps: After the second consensus node generates a cross-chain consensus block based on the cross-chain consensus result, it performs pre-commit processing on the cross-chain consensus block based on the second business branch chain. This pre-commit processing includes: pre-committing the cross-chain consensus block to the second business branch chain. Pre-committing means adding the generated block to the blockchain first, but the block's status is pending; that is, the block added to the blockchain may be valid or invalid, requiring subsequent configuration.

[0086] After the first consensus node completes the state setting for the cross-chain business block, it can store the state setting result for the cross-chain business block in the first cross-chain storage space. This state setting result may include the state declaration block (including the first state declaration block or the second state declaration block) generated above for making state declarations for the cross-chain business block.

[0087] The second consensus node retrieves the state setting result of the cross-chain business block from the first cross-chain storage space and sets the state of the cross-chain consensus block to be submitted to the second business branch chain based on the state setting result. In a feasible embodiment, when the state of the cross-chain business block indicated by the state setting result (or declared by the state declaration block) matches the cross-chain consensus result, the state of the cross-chain consensus block to be submitted to the second business branch chain is set to a valid state. This means that the business consensus node of the first business branch chain (or the first consensus node) sets the state of the cross-chain business block to be submitted to the first business branch chain based on the cross-chain consensus result of the business consensus node of the second business branch chain. Similarly, a third state declaration block can be added after the cross-chain consensus block on the second business branch chain to declare the state of the cross-chain consensus block. This third state declaration block is used to declare the cross-chain consensus block on the second business branch chain as valid. The matching includes: the cross-chain consensus result indicating that the cross-chain business block failed to pass the cross-chain consensus, and the state setting result indicating that the state of the cross-chain business block is invalid; or, the cross-chain consensus result indicating that the cross-chain business block passed the cross-chain consensus, and the state setting result indicating that the state of the cross-chain business block is valid.

[0088] In a feasible embodiment, when the state of the cross-chain business block indicated by the state setting result (or declared by the state declaration block) does not match the cross-chain consensus result, the state of the cross-chain consensus block pre-submitted to the second business branch chain is set to an invalid state. This means that the business consensus node (or the first consensus node) of the first business branch chain did not set the state of the cross-chain business block pre-submitted to the first business branch chain based on the cross-chain consensus result of the cross-chain business block from the business consensus node of the second business branch chain. Similarly, a fourth state declaration block can be added after the cross-chain consensus block on the second business branch chain to declare the state of the cross-chain consensus block. This fourth state declaration block declares the cross-chain consensus block on the second business branch chain as invalid. The mismatch includes: the cross-chain consensus result indicating that the cross-chain business block's cross-chain consensus failed, while the state setting result indicates that the cross-chain business block's state is valid; or, the cross-chain consensus result indicating that the cross-chain business block's cross-chain consensus passed, while the state setting result indicates that the cross-chain business block's state is invalid.

[0089] This situation may be caused by a discrepancy between the cross-chain consensus result of the second business branch chain's business consensus node on the cross-chain business block obtained by the first consensus node and the actual cross-chain consensus result of the second business branch chain's business consensus node on the cross-chain business block. The discrepancy could be caused by malicious tampering with the cross-chain consensus result of the cross-chain business block stored in the second cross-chain storage space. To address this, the main chain consensus node of the main business chain can reset the state of the cross-chain business block on the first business branch chain based on the actual cross-chain consensus result of the second business branch chain's business consensus node when it detects that the cross-chain consensus block on the second business branch chain is invalid.

[0090] Furthermore, after the second consensus node completes the state setting for the cross-chain consensus block, it can store the state setting result for the cross-chain consensus block in the second cross-chain storage space. This state setting result can include the state declaration block (including the third or fourth state declaration block) generated above for making state declarations for the cross-chain consensus block. At this point, the second consensus node has completed its processing of the cross-chain business (or the target business, or the cross-chain business block). If the first consensus node obtains the state setting result of the cross-chain consensus block from the second cross-chain storage space, it can also determine that it has ended its processing of the cross-chain business. After the completion of cross-chain business processing is detected, or after the validity period of access permissions is detected, the main chain consensus node of the main business chain may revoke the access permissions of the first business branch chain's business consensus node (including the first consensus node) to the second cross-chain storage space (or the first business branch chain's business consensus node may voluntarily relinquish its access permissions to the second cross-chain storage space, and subsequent access will require re-application), and / or, the main chain consensus node of the main business chain may revoke the access permissions of the second business branch chain's business consensus node (including the second consensus node) to the first cross-chain storage space (or the second business branch chain's business consensus node may voluntarily relinquish its access permissions to the first cross-chain storage space, and subsequent access will require re-application).

[0091] In one embodiment, upon detecting that the first access permission revocation condition is met, including: detecting the completion of the relevant processing of the cross-chain business, and / or detecting that the effective time for the business consensus node (including the first consensus node) of the first business branch chain to have access to the second cross-chain storage space has been reached, the main chain consensus node of the business main chain revokes the access permission of the business consensus node (including the first consensus node) of the first business branch chain to the second cross-chain storage space, and generates a first permission revocation indication message to indicate that the main chain consensus node has revoked the access permission of the business consensus node (including the first consensus node) of the first business branch chain to the second cross-chain storage space, and then sends the first permission revocation indication message to the business consensus node (including the first consensus node) of the first business branch chain, so that the business consensus node (including the first consensus node) of the first business branch chain is aware that it has lost access permission to the second cross-chain storage space, and subsequent access to the second cross-chain storage space will require reapplying for access permission.

[0092] Similarly, upon detecting that the second access permission revocation conditions are met, including: detecting the completion of relevant cross-chain business processing, and / or detecting that the effective time for the business consensus node (including the second consensus node) of the second business branch chain to have access to the first cross-chain storage space has been reached, the main chain consensus node of the main chain revokes the access permission of the business consensus node (including the second consensus node) of the second business branch chain to the first cross-chain storage space, and generates a second permission revocation indication message to indicate that the main chain consensus node has revoked the access permission of the business consensus node (including the second consensus node) of the second business branch chain to the first cross-chain storage space, and then sends the second permission revocation indication message to the business consensus node (including the second consensus node) of the second business branch chain, so that the business consensus node (including the second consensus node) of the second business branch chain is aware that it has lost access permission to the first cross-chain storage space, and subsequent access to the first cross-chain storage space will require reapplying for access permission.

[0093] It should be noted that if, before the relevant processing of cross-chain business is completed, the effective time for the business consensus node (including the first consensus node) of the first business branch chain to have access to the second cross-chain storage space has been reached, or the effective time for the business consensus node (including the second consensus node) of the second business branch chain to have access to the first cross-chain storage space has been reached, then the first consensus node or the second consensus node can reapply (or apply for renewal) to the main chain consensus node of the main business chain for access to the corresponding cross-chain storage space.

[0094] This application embodiment first pre-submits the cross-chain business block generated by the first consensus node of the first business branch chain to the first business branch chain. Then, the second consensus node of the second business branch chain performs cross-chain consensus on the cross-chain business block. Finally, the first consensus node sets the status of the cross-chain business block pre-submitted to the first business branch chain according to the cross-chain consensus result. This enables cross-chain consensus processing of cross-chain business. On the other hand, different dedicated storage spaces are allocated to different business branch chains for storing cross-chain data. The cross-chain data involved in a certain business branch chain is stored in its dedicated storage space. In this way, the business consensus nodes of other business branch chains that need to process based on the cross-chain data can directly obtain the cross-chain data from the dedicated storage space, which is more efficient than obtaining the cross-chain data directly from the business branch chain. Furthermore, when a business consensus node of a certain business branch chain wants to obtain cross-chain data from the dedicated storage space of other business branch chains, it needs to obtain permission to access the dedicated storage space of other business branch chains first. This can effectively ensure the security of the data stored in the dedicated storage spaces of each business branch chain.

[0095] The previous text introduced how the first consensus node of the first business branch chain generates the cross-chain business block, and how the business consensus node of the first business branch chain can conduct preliminary consensus on the cross-chain business block, and then the business consensus node (including the second consensus node) of the second business branch chain conducts cross-chain consensus on the cross-chain business block. It can be understood that the business consensus nodes of two or more business branch chains can also conduct cross-chain consensus on the cross-chain business block. For example, in a tax scenario, the first business branch chain is the blockchain maintaining the invoice business within the blockchain network corresponding to the tax scenario; the second business branch chain is the blockchain maintaining the credit reporting business within the blockchain network corresponding to the tax scenario; and the third business branch chain is the blockchain maintaining the enterprise qualification business within the blockchain network corresponding to the tax scenario. The target business is issuing invoices. The business consensus nodes of the first business branch chain perform initial consensus on this cross-chain business block, which could be based on consensus on invoice-related data (such as invoice amount, invoice date, company name, and NARIE ID number). Meanwhile, the business consensus nodes of the second business branch chain perform cross-chain consensus on this cross-chain business block, which could be based on consensus on the credit reporting of the invoice recipient (such as Company A). Similarly, the business consensus nodes of the third business branch chain perform cross-chain consensus on this cross-chain business block, which could be based on consensus on the enterprise qualification of the invoice recipient (such as Company A). If the cross-chain consensus results of the business consensus nodes of the second business branch chain and the cross-chain consensus results of the business consensus nodes of the third business branch chain for the cross-chain business block are both passed, then the business consensus nodes of the first business branch chain will set the status of the cross-chain business block pre-submitted to the first business branch chain to a valid state.

[0096] It should be noted that the specific implementation method for this situation can refer to the cross-chain consensus method described above, and will not be repeated here. In addition, it can be understood that, for this situation, the second business branch chain described in the above embodiments can be two or more, each corresponding to different businesses, and the second consensus node, second storage space, and cross-chain consensus result can also be two or more.

[0097] Additionally, it's worth noting that blockchain networks can include single-layer, two-layer, or multi-layer networks. Here, "layer" refers to the number of sub-networks within the blockchain network. The division of sub-networks can be based on considerations such as business needs, communication connectivity, and security. Inter-network access between blockchain nodes within the same sub-network is secured by a consensus mechanism, while inter-network access between blockchain nodes in different sub-networks requires additional identity management and / or network control. For example, Figure 2 The illustrated blockchain network is a single-layer blockchain network, in which secure access and data synchronization can be achieved between blockchain nodes through a consensus mechanism. In one implementation, the blockchain-based block processing method provided in this application embodiment can be applied to… Figure 2 In the single-layer blockchain network shown, under this implementation, the main chain consensus node and business consensus node mentioned in the embodiments of this application are consensus nodes belonging to the single-layer blockchain network.

[0098] Among other feasible implementations, the blockchain-based block processing method proposed in this application can be applied not only to the single-layer blockchain network described above (such as a single blockchain network), but also to more complex two-layer or multi-layer blockchain networks. For example, when blockchain is applied in certain scenarios, such as bill business scenarios, data storage scenarios for government or commercial institutions, etc., not all nodes in the blockchain network have sufficient resources and necessity to become nodes participating in blockchain consensus. Furthermore, for data security considerations, the commonly used data-peer blockchain deployment method is not suitable when dealing with data related to personal privacy or national security in the blockchain system. To adapt to business needs (such as separation of internal and external networks, business networks, and office networks), and to further improve data security and confidentiality, this application provides a two-layer chain, forming a two-layer network architecture of "witness sub-network - consensus sub-network" through a P2P (Peer to Peer) network. Here, the P2P network is a peer-to-peer connection network, and the nodes connected in a peer-to-peer manner are called peer nodes. P2P networks are based on a specific network protocol that eliminates the need for a central node to maintain the network state. Each node maintains the overall network state and its connection status with neighboring nodes through broadcast interactions with neighboring nodes.

[0099] Figure 7 This application illustrates an exemplary embodiment of an architecture diagram of a two-layer blockchain network; as shown... Figure 7 As shown, the blockchain network includes a witness subnetwork and a consensus subnetwork. Specifically: ① The witness subnetwork includes one or more business nodes, meaning these business nodes are deployed in the public witness subnetwork. These business nodes primarily execute business logic, do not participate in the accounting consensus, and obtain block header data and partially authorized visible block data from the consensus subnetwork through identity authentication. ② The consensus subnetwork is the core network of the blockchain network, used for accounting consensus. It includes one or more consensus nodes (or accounting nodes), or as described above... Figure 4 The consensus subnetwork shown contains one or more consensus clusters, each containing consensus nodes that deploy and run the blockchain consensus protocol, including source and target consensus nodes. Based on this, the cross-chain consensus processing between the aforementioned first and second business branch chains is performed within the consensus subnetwork of the two-layer network architecture. Typically, the witness subnetwork and the consensus subnetwork exist in different network environments: the witness subnetwork is in a public network, while the consensus subnetwork is in a private network. Since the consensus subnetwork is in a relatively secure private network, its mutual access is inherently secure due to the consensus mechanism, eliminating the need for additional identity management and network control. However, business nodes are located in a public network and may be accessed by other uncertain network terminals; therefore, the access of business nodes and other potential nodes to the consensus subnetwork needs to be strictly controlled.

[0100] Furthermore, the aforementioned witness sub-network and consensus sub-network can interact through a routing proxy network (or routing boundary network) between them. Specifically, the routing proxy network belongs to the blockchain network and is used to isolate the witness sub-network and consensus sub-network. The routing proxy network contains one or more routing proxy nodes, which can forward data sent by business nodes in the witness sub-network to consensus nodes in the consensus sub-network through the routing proxy nodes, thereby improving the security of data in the consensus sub-network. For a more detailed architectural diagram of the two-layer blockchain network provided in this embodiment, please refer to [link to relevant documentation]. Figure 8 .

[0101] like Figure 8As shown, the blockchain network comprises a business layer, a routing proxy layer, and a core consensus network layer. These three layers together form the complete blockchain business system. Specifically: ① The business layer resides in the witness sub-network and includes at least one business node, which can be an SPV node. The SPV node maintains a normal unstructured P2P network and can handle business such as taxation (local tax bureau), invoicing (corporate invoicing), and payment (corporate cash flow). ② The core consensus network layer resides in the consensus sub-network and includes multiple consensus nodes with consensus functions, such as consensus node 801, consensus node 802, consensus node 803, and so on. ③ The routing proxy layer includes at least one proxy node, which can provide routing services, authentication services, certificate caching services, and peer-to-peer (P2P) services. The business layer and the core consensus network layer interact through the routing proxy layer. Specifically, the business layer submits business operation interactions to the core consensus network layer through the routing proxy layer, thus isolating the business layer from the core consensus network layer.

[0102] As mentioned above Figure 4 As can be seen from the relevant descriptions, the core consensus network layer (i.e., the consensus sub-network) can also include multiple consensus clusters, such as... Figure 8 The core consensus network shown may include a consensus cluster 804, which may include consensus nodes 801 and 802 to maintain the core chain 1 within the cluster. This application embodiment does not limit whether the core consensus layer includes consensus nodes or a consensus cluster; this is only a clarification. Furthermore, in this application embodiment, depending on whether the chain maintained by the consensus cluster is the main business chain or a business branch chain, multiple consensus clusters are divided into a main chain consensus cluster (or core consensus cluster) and branch chain consensus clusters. For details regarding the main chain consensus cluster and branch chain consensus clusters, please refer to the foregoing. Figure 4 The specific implementation details shown are not elaborated here.

[0103] The following is combined Figure 9 This section introduces a two-layer network architecture; such as... Figure 9As shown, the blockchain network includes a witness sub-network, a routing proxy network, and a consensus sub-network. ① In the witness sub-network, business nodes (such as SPV nodes) are dynamically configured with chain identifiers for the main business chain and / or one or more business branch chains. This allows business nodes in the witness sub-network to participate in the business operations of the business branch chains (e.g., accessing or storing business data of the same business type as the business branch chain). ② Similarly, the main business chain in the consensus sub-network also registers the node identifiers and addresses of the business nodes in the witness sub-network. A business branch chain can obtain the node identifier and address of a specific business node from the main business chain and then synchronize the business data stored in the business branch chain to the business node for local storage. ③ The routing proxy network records the node information of consensus nodes in the consensus sub-network. The node information may include the node identifier, the chain identifier of the stored blockchain (such as the main business chain or the business branch chain), etc. When a routing proxy node in the routing proxy network encounters a business data to be sent to a business branch chain, it can directly forward the business data to the corresponding business consensus node. Otherwise, the routing proxy node will forward the business data to the main chain consensus node that maintains the main business chain, and the main chain consensus node will process the business data according to the chain identifier of each business branch chain derived from the main business chain (such as forwarding it to the corresponding business branch chain).

[0104] When the blockchain-based block processing method provided in this application is applied... Figure 9 In the two-layer network architecture shown, the service node in the witness subnetwork can send a service processing request to the routing agent node in the routing agent network. This service processing request may include the target service to be processed. Then, the routing agent node in the routing agent network determines the service branch chain that matches the service type of the target service based on the recorded service types of each service branch chain, and sends the target service to the service consensus node of the matching service branch chain for processing. The specific processing procedure can be referred to the previous description and will not be repeated here.

[0105] In addition, the data consensus involved in the embodiments of this application can be verified by using any of the following consensus algorithms.

[0106] 1) Pow (Proof-of-Work) refers to a measurement method set up by a system (such as the aforementioned data sharing system) to achieve a certain goal. Simply put, it is a proof used to confirm the amount of work done. Essentially, whoever does more work has a greater chance of receiving additional rewards.

[0107] 2) Proof-of-Stake (PoS) is an upgraded consensus mechanism of Proof-of-Work (PoW). Specifically, the longer a node holds electronic resources (holding time = quantity of electronic resources * holding time), the greater its chance of acquiring the right to record blocks. Electronic resources refer to resources stored electronically in electronic accounts and circulated via the internet. The difficulty of acquiring resources is proportionally reduced based on the proportion and duration of each node's electronic resources, thus accelerating the process of finding random numbers. While PoS shortens the consensus time to some extent, it still requires resource acquisition.

[0108] 3) DPoS (Delegated Proof of Stake) is a stake-based proof-of-stake mechanism similar to holders of electronic resources voting for a certain number of nodes to act as their proxies for verification and record-keeping. To incentivize more participation, the system generates a small amount of electronic resources as a reward. DPoS involves each holder of electronic resources voting to produce 101 representatives, which can be understood as 101 supernodes, all with equal rights. If elected representatives fail to fulfill their duties (failing to produce blocks when it's their turn), they are removed, and the network elects new supernodes to replace them. This allows DPoS to significantly reduce the number of nodes involved in verification and record-keeping, achieving consensus verification in seconds, but the entire consensus mechanism still relies on electronic resources.

[0109] 4) PBFT (Practical Byzantine Fault Tolerance) is a message-passing-based consensus algorithm. It achieves consensus through three phases, which may be repeated if failures occur. Specifically, assuming a total of 3f+1 nodes, where f represents the Byzantine faulty node, first, when a node discovers that the leader (e.g., a representative node, ledger node, or supernode) is acting maliciously, it elects another replica node as the new leader. Second, the leader broadcasts its chosen value to the other replica nodes via a pre-prepare message. Other replica nodes send a prepare message if they accept it, otherwise they do not. Third, once 2f nodes accept the prepare message, the node sends a commit message. Finally, when 2f+1 nodes accept the commit message, the value is considered finalized. The above process enables the PBFT Byzantine Fault Tolerance algorithm to reach a consensus that each node is composed of business participants or regulators, and that security and stability are guaranteed by business stakeholders. Furthermore, the consensus latency is approximately 2 to 5 seconds, which basically meets the requirements of commercial real-time processing, improves consensus efficiency, and can meet the needs of high-frequency trading.

[0110] 5) Paxos (a distributed algorithm) is a two-phase algorithm with three main roles: proposer, acceptor, and learner. The proposer proposes a proposal, the acceptor agrees or rejects, and the learner obtains the final value after consensus is reached. The Paxos algorithm consists of two phases: ① Preparation phase: The proposer selects a proposal number n and sends a prepare request to a majority of acceptors; after receiving the prepare request, if the acceptor's proposal number is greater than all prepare requests it has already responded to, the acceptor replies to the proposer with the proposal it previously accepted and promises not to respond to proposals less than n. ② Approval Phase: Once a proposer receives responses to the prepare request from a majority of acceptors, it enters the approval phase. It sends an accept request to the acceptors that responded to the prepare request, including the number n and the value (if there is no value that has already been accepted, it can freely decide the value). Without violating its commitments to other proposers, the acceptor accepts the request upon receiving it.

[0111] 6) Raft (a distributed consensus algorithm) includes three roles: follower, candidate, and leader. A node can only be in one of these three states at any given time, and these roles can transform into each other over time and under changing conditions. All nodes initially start as followers. Followers that do not receive a heartbeat within a timeout period become candidates and broadcast a vote request. The node that receives a majority of votes becomes the leader. In this round of voting, whoever sends the request first has the advantage, and each node only gives one vote. The leader node periodically sends heartbeats to other nodes. Leader node failure will trigger a new round of voting.

[0112] This application does not limit which consensus algorithm or one consensus algorithm is used in the embodiments, which is not specified here.

[0113] Furthermore, it should be noted that the execution entity used to perform the steps in the above method embodiments can be hardware, software, or a combination of both. Additionally, in the specific embodiments of this application, data related to target business, invoice-related data, invoicing objects, characteristic data, credit data, etc., are involved, and all data used is authorized by the user. When the above embodiments of this application are applied to specific products or technologies, the data used must obtain user permission or consent, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0114] Please see Figure 10 This is a schematic diagram of a blockchain-based block processing device provided in an embodiment of this application. The blockchain includes a main business chain, a first business branch chain, and a second business branch chain. The first business branch chain corresponds to a first cross-chain storage space, and the second business branch chain corresponds to a second cross-chain storage space. The main chain consensus node of the main business chain allocates access permissions to the second cross-chain storage space to the first consensus node of the first business branch chain, and allocates access permissions to the first cross-chain storage space to the second consensus node of the second business branch chain. In feasible embodiments, the blockchain-based block processing device described in this application embodiment can correspond to the first consensus node mentioned above, and the device includes: Processing unit 1001 is used to generate a cross-chain business block for the target business if the target business meets the cross-chain consensus conditions; The processing unit 1001 is also used to perform pre-commit processing on the cross-chain business block based on the first business branch chain; Communication unit 1002 is used to store the cross-chain business block into the first cross-chain storage space; The communication unit 1002 is further configured to obtain cross-chain consensus results regarding the cross-chain business block from the second cross-chain storage space; wherein, the cross-chain consensus results are obtained by the second consensus node obtaining the cross-chain business block from the first cross-chain storage space and performing cross-chain consensus on the cross-chain business block; The processing unit 1001 is also used to set the status of the cross-chain business blocks to be submitted to the first business branch chain based on the cross-chain consensus result.

[0115] In one embodiment, when the processing unit 1001 sets the status of the cross-chain business block to be submitted to the first business branch chain based on the cross-chain consensus result, it is specifically used for: If the cross-chain consensus of the cross-chain business block is determined to have passed based on the cross-chain consensus result, the status of the cross-chain business block pre-submitted to the first business branch chain is set to a valid status; if the cross-chain consensus of the cross-chain business block is determined to have failed based on the cross-chain consensus result, the status of the cross-chain business block pre-submitted to the first business branch chain is set to an invalid status.

[0116] In one embodiment, the processing unit 1001 is further configured to determine a consensus node for cross-chain consensus for the target business; The communication unit 1002 is further configured to obtain the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space if the consensus node for cross-chain consensus for the target business includes the business consensus node of the second business branch chain.

[0117] In one embodiment, the communication unit 1002 is further configured to send a cross-chain consensus request to the business consensus node of the second business branch chain; wherein the cross-chain consensus request carries the block identifier of the cross-chain business block; the cross-chain consensus request is used to request the business consensus node of the second business branch chain to obtain the cross-chain business block from the first cross-chain storage space based on the block identifier, and to perform cross-chain consensus on the cross-chain business block.

[0118] In one embodiment, the processing unit 1001 is further configured to perform initial consensus on the cross-chain business block; If the initial consensus result indicates that the cross-chain business block consensus has passed, then the cross-chain business block is pre-committed based on the first business branch chain, and the communication unit 1002 is triggered to store the cross-chain business block in the first cross-chain storage space.

[0119] In one embodiment, the communication unit 1002 is further configured to receive permission revocation indication information sent by the main chain consensus node; wherein, the permission revocation indication information is used to instruct the main chain consensus node to revoke the first consensus node's access permission to the second cross-chain storage space; the permission revocation indication information is generated by the main chain consensus node when it detects that the access permission revocation conditions are met, and the access permission revocation conditions include: the validity period of the access permission has been reached, or the relevant processing of the cross-chain business block has been completed, or the validity period of the access permission has been reached and the relevant processing of the cross-chain business block has been completed.

[0120] In other feasible embodiments, the blockchain-based block processing device described in this application embodiment can correspond to the second consensus node mentioned above, and the device includes: The communication unit 1002 is used to obtain a cross-chain business block from the first cross-chain storage space; wherein, the cross-chain business block is generated and stored in the first cross-chain storage space by the first consensus node for the target business when the target business meets the cross-chain consensus conditions; Processing unit 1001 is used to perform cross-chain consensus on the cross-chain business block and determine the cross-chain consensus result; The communication unit 1002 is further configured to store the cross-chain consensus result in the second cross-chain storage space, so that the first consensus node can obtain the cross-chain consensus result from the second cross-chain storage space and set the status of the cross-chain business block to be submitted to the first business branch chain based on the cross-chain consensus result.

[0121] In one embodiment, the processing unit 1001 is further configured to generate a cross-chain consensus block for the cross-chain consensus result, and perform pre-commit processing on the cross-chain consensus block based on the second business branch chain; The communication unit 1002 is also used to obtain the status setting result of the cross-chain business block stored by the first consensus node from the first cross-chain storage space; The processing unit 1001 is further configured to set the status of the cross-chain consensus block to be submitted to the second business branch chain based on the status setting result.

[0122] In one embodiment, when the communication unit 1002 stores the cross-chain consensus result to the second cross-chain storage space, it is specifically used to: store the cross-chain consensus block to the second cross-chain storage space; wherein, the first consensus node obtains the cross-chain consensus block from the second cross-chain storage space and extracts the cross-chain consensus result from the cross-chain consensus block.

[0123] In one embodiment, the communication unit 1002 is further configured to: Receive a cross-chain consensus request sent by the first consensus node; wherein the cross-chain consensus request carries the block identifier of the cross-chain business block; respond to the cross-chain consensus request and retrieve the cross-chain business block from the first cross-chain storage space based on the block identifier.

[0124] In one embodiment, the communication unit 1002 is further configured to: receive permission revocation indication information sent by the main chain consensus node; wherein the permission revocation indication information is used to instruct the main chain consensus node to revoke the second consensus node's access permission to the first cross-chain storage space; the permission revocation indication information is generated by the main chain consensus node when it detects that the access permission revocation conditions are met, and the access permission revocation conditions include: the validity period of the access permission has been reached, or the relevant processing of the cross-chain business block has been completed, or the validity period of the access permission has been reached and the relevant processing of the cross-chain business block has been completed.

[0125] It is understood that the functions of each functional unit of the blockchain-based block processing device provided in this application embodiment can be specifically implemented according to the relevant 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.

[0126] In feasible embodiments, the blockchain-based block processing device provided in this application can be implemented in software. The blockchain-based block processing device can be stored in a memory and can be software in the form of programs and plug-ins, and includes a series of units, including processing units and communication units; wherein, the processing units and communication units are used to implement the blockchain-based block processing method provided in this application.

[0127] In other feasible embodiments, the blockchain-based block processing device provided in this application embodiment can also be implemented in a combination of hardware and software. As an example, the blockchain-based block processing device provided in this application embodiment can be a processor in the form of a hardware decoding processor, which is programmed to execute the block processing method provided in this application embodiment. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0128] This application embodiment first pre-submits the cross-chain business block generated by the first consensus node of the first business branch chain to the first business branch chain. Then, the second consensus node of the second business branch chain performs cross-chain consensus on the cross-chain business block. Finally, the first consensus node sets the status of the cross-chain business block pre-submitted to the first business branch chain according to the cross-chain consensus result. This enables cross-chain consensus processing of cross-chain business. On the other hand, different dedicated storage spaces are allocated to different business branch chains for storing cross-chain data. The cross-chain data involved in a certain business branch chain is stored in its dedicated storage space. In this way, the business consensus nodes of other business branch chains that need to process based on the cross-chain data can directly obtain the cross-chain data from the dedicated storage space, which is more efficient than obtaining the cross-chain data directly from the business branch chain. Furthermore, when a business consensus node of a certain business branch chain wants to obtain cross-chain data from the dedicated storage space of other business branch chains, it needs to obtain permission to access the dedicated storage space of other business branch chains first. This can effectively ensure the security of the data stored in the dedicated storage spaces of each business branch chain.

[0129] Please see Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device described in this embodiment includes: a processor 1101, a communication interface 1102, and a memory 1103. The processor 1101, communication interface 1102, and memory 1103 can be connected via a bus or other means; this embodiment takes a bus connection as an example.

[0130] The processor 1101 (or CPU (Central Processing Unit)) is the computing and control core of the computer device. It can parse various instructions and process various data within the computer device. For example, the CPU can parse power-on / off commands sent by the user and control the computer device to perform power-on / off operations; it can also transmit various interactive data between internal structures of the computer device. The communication interface 1102 may optionally include standard wired interfaces or wireless interfaces (such as Wi-Fi, mobile communication interfaces, etc.), and is controlled by the processor 1101 for sending and receiving data. The memory 1103 is the storage device in the computer device, used to store programs and data. It is understood that the memory 1103 here can include the computer device's built-in memory, or it can include extended memory supported by the computer device. The memory 1103 provides storage space, which stores the computer device's operating system, including but not limited to: Android system, iOS system, Windows Phone system, etc., which this application does not limit.

[0131] In this embodiment of the application, the computer device is used to implement the blockchain-based block processing method in the preceding embodiments, wherein the blockchain includes a business main chain, a first business branch chain and a second business branch chain, the first business branch chain corresponds to a first cross-chain storage space, the second business branch chain corresponds to a second cross-chain storage space, the main chain consensus node of the business main chain allocates access permissions to the second cross-chain storage space to the first consensus node of the first business branch chain, and allocates access permissions to the first cross-chain storage space to the second consensus node of the second business branch chain.

[0132] In a feasible embodiment, the computer device may correspond to the first consensus node described above. In this case, the processor 1101 performs the following operations by running the executable program code in the memory 1104: If the target business meets the cross-chain consensus conditions, a cross-chain business block is generated for the target business; the cross-chain business block is pre-committed based on the first business branch chain, and the cross-chain business block is stored in the first cross-chain storage space through communication interface 1102; the cross-chain consensus result of the cross-chain business block is obtained from the second cross-chain storage space through communication interface 1102; wherein, the cross-chain consensus result is obtained by the second consensus node obtaining the cross-chain business block from the first cross-chain storage space and performing cross-chain consensus on the cross-chain business block; the status of the cross-chain business block pre-committed to the first business branch chain is set based on the cross-chain consensus result.

[0133] In one embodiment, when the processor 1101 sets the status of the cross-chain business block to be submitted to the first business branch chain based on the cross-chain consensus result, it is specifically configured to: if it is determined based on the cross-chain consensus result that the cross-chain business block has passed the cross-chain consensus, then set the status of the cross-chain business block to be submitted to the first business branch chain to a valid state; if it is determined based on the cross-chain consensus result that the cross-chain business block has failed the cross-chain consensus, then set the status of the cross-chain business block to be submitted to the first business branch chain to an invalid state.

[0134] In one embodiment, the processor 1101 is further configured to: determine a consensus node for cross-chain consensus for the target business; if the consensus node for cross-chain consensus for the target business includes the business consensus node of the second business branch chain, then obtain the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space through the communication interface 1102.

[0135] In one embodiment, the processor 1101 is further configured to: send a cross-chain consensus request to the business consensus node of the second business branch chain via the communication interface 1102; wherein the cross-chain consensus request carries the block identifier of the cross-chain business block; the cross-chain consensus request is used to request the business consensus node of the second business branch chain to obtain the cross-chain business block from the first cross-chain storage space based on the block identifier, and to perform cross-chain consensus on the cross-chain business block.

[0136] In one embodiment, the processor 1101 is further configured to: perform initial consensus on the cross-chain business block; if the initial consensus result indicates that the cross-chain business block consensus has passed, then perform pre-commit processing on the cross-chain business block based on the first business branch chain, and store the cross-chain business block in the first cross-chain storage space through the communication interface 1102.

[0137] In one embodiment, the processor 1101 is further configured to: receive permission revocation indication information sent by the main chain consensus node through the communication interface 1102; wherein, the permission revocation indication information is used to instruct the main chain consensus node to revoke the first consensus node's access permission to the second cross-chain storage space; the permission revocation indication information is generated by the main chain consensus node when it detects that the access permission revocation conditions are met, and the access permission revocation conditions include: the validity period of the access permission has been reached, or the relevant processing of the cross-chain business block has been completed, or the validity period of the access permission has been reached and the relevant processing of the cross-chain business block has been completed.

[0138] In other feasible embodiments, the computer device may correspond to the second consensus node described above. In this case, the processor 1101 performs the following operations by running the executable program code in the memory 1104: The cross-chain business block is obtained from the first cross-chain storage space through communication interface 1102; wherein, the cross-chain business block is generated and stored in the first cross-chain storage space by the first consensus node for the target business when the target business meets the cross-chain consensus conditions; cross-chain consensus is performed on the cross-chain business block to determine the cross-chain consensus result; the cross-chain consensus result is stored in the second cross-chain storage space through communication interface 1102 so that the first consensus node can obtain the cross-chain consensus result from the second cross-chain storage space and set the status of the cross-chain business block to be submitted to the first business branch chain based on the cross-chain consensus result.

[0139] In one embodiment, the processor 1101 is further configured to: generate a cross-chain consensus block for the cross-chain consensus result; perform pre-commit processing on the cross-chain consensus block based on the second business branch chain; obtain the state setting result of the cross-chain business block stored by the first consensus node from the first cross-chain storage space through the communication interface 1102; and set the state of the cross-chain consensus block pre-committed to the second business branch chain based on the state setting result.

[0140] In one embodiment, when the processor 1101 stores the cross-chain consensus result to the second cross-chain storage space, it is specifically used to: store the cross-chain consensus block to the second cross-chain storage space through the communication interface 1102; wherein, the first consensus node obtains the cross-chain consensus block from the second cross-chain storage space and extracts the cross-chain consensus result from the cross-chain consensus block.

[0141] In one embodiment, the processor 1101 is further configured to: receive a cross-chain consensus request sent by the first consensus node through a communication interface 1102; wherein the cross-chain consensus request carries a block identifier of the cross-chain business block; and in response to the cross-chain consensus request, obtain the cross-chain business block from the first cross-chain storage space based on the block identifier through the communication interface 1102.

[0142] In one embodiment, the processor 1101 is further configured to: receive permission revocation indication information sent by the main chain consensus node through the communication interface 1102; wherein, the permission revocation indication information is used to instruct the main chain consensus node to revoke the second consensus node's access permission to the first cross-chain storage space; the permission revocation indication information is generated by the main chain consensus node when it detects that the access permission revocation conditions are met, and the access permission revocation conditions include: the validity period of the access permission has been reached, or the relevant processing of the cross-chain business block has been completed, or the validity period of the access permission has been reached and the relevant processing of the cross-chain business block has been completed.

[0143] In specific implementations, the processor 1101, communication interface 1102, and memory 1103 described in the embodiments of this application can execute the implementation of the first consensus node or the second consensus node described in the blockchain-based block processing method provided in the embodiments of this application, or they can execute the implementation of the blockchain-based block processing device provided in the embodiments of this application, which will not be repeated here.

[0144] This application embodiment first pre-submits the cross-chain business block generated by the first consensus node of the first business branch chain to the first business branch chain. Then, the second consensus node of the second business branch chain performs cross-chain consensus on the cross-chain business block. Finally, the first consensus node sets the status of the cross-chain business block pre-submitted to the first business branch chain according to the cross-chain consensus result. This enables cross-chain consensus processing of cross-chain business. On the other hand, different dedicated storage spaces are allocated to different business branch chains for storing cross-chain data. The cross-chain data involved in a certain business branch chain is stored in its dedicated storage space. In this way, the business consensus nodes of other business branch chains that need to process based on the cross-chain data can directly obtain the cross-chain data from the dedicated storage space, which is more efficient than obtaining the cross-chain data directly from the business branch chain. Furthermore, when a business consensus node of a certain business branch chain wants to obtain cross-chain data from the dedicated storage space of other business branch chains, it needs to obtain permission to access the dedicated storage space of other business branch chains first. This can effectively ensure the security of the data stored in the dedicated storage spaces of each business branch chain.

[0145] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, enables the computer to implement the blockchain-based block processing method as described in this application. The specific implementation method can be found in the preceding description and will not be repeated here.

[0146] Accordingly, this application also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the blockchain-based block processing method provided in this application.

[0147] Accordingly, this application also provides a computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based block processing method provided in this application.

[0148] 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.

[0149] 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: flash drive, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0150] 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 blockchain-based block processing method, characterized in that, The blockchain includes a main business chain, a first business branch chain, and a second business branch chain. The first business branch chain corresponds to a first cross-chain storage space, and the second business branch chain corresponds to a second cross-chain storage space. The main chain consensus node of the main business chain allocates access permissions to the second cross-chain storage space to the first consensus node of the first business branch chain, and allocates access permissions to the first cross-chain storage space to the second consensus node of the second business branch chain. The method includes: If the target business meets the cross-chain consensus conditions, then a cross-chain business block is generated for the target business; Based on the first business branch chain, the cross-chain business block is pre-submitted, and the cross-chain business block is stored in the first cross-chain storage space; the state of the block pre-submitted to the business branch chain is pending. The cross-chain consensus block stored by the second consensus node is obtained from the second cross-chain storage space, and the cross-chain consensus result about the cross-chain business block is extracted from the cross-chain consensus block; wherein, the cross-chain consensus result is obtained by the second consensus node from the first cross-chain storage space to obtain the cross-chain business block and perform cross-chain consensus on the cross-chain business block; Based on the cross-chain consensus result, a first state declaration block is added after the cross-chain business block on the first business branch chain. The first state declaration block is used to declare whether the cross-chain business block on the first business branch chain is valid or invalid. The first state declaration block is stored in the first cross-chain storage space; the stored first state declaration block is used by the second consensus node to retrieve from the first cross-chain storage space, and based on the retrieved first state declaration block, to add a second state declaration block after the cross-chain consensus block on the second business branch chain; the cross-chain consensus block is generated by the second consensus node for the cross-chain consensus result and pre-submitted to the second business branch chain; the second state declaration block is used to declare whether the cross-chain consensus block on the second business branch chain is valid or invalid.

2. The method as described in claim 1, characterized in that, The step of adding a first state declaration block after the cross-chain business block on the first business branch chain based on the cross-chain consensus result includes: If the cross-chain consensus of the cross-chain business block is determined to be successful based on the cross-chain consensus result, then a first state declaration block for declaring the validity of the cross-chain business block on the first business branch chain is added after the cross-chain business block on the first business branch chain. If, based on the cross-chain consensus result, it is determined that the cross-chain business block has failed to pass cross-chain consensus, then a first state declaration block is added after the cross-chain business block on the first business branch chain to declare that the cross-chain business block on the first business branch chain is invalid.

3. The method as described in claim 1, characterized in that, The method further includes: Identify the consensus node for cross-chain consensus regarding the target business; If the consensus node for cross-chain consensus on the target business includes the business consensus node of the second business branch chain, then the step of obtaining the cross-chain consensus result of the cross-chain business block from the second cross-chain storage space is executed.

4. The method as described in claim 3, characterized in that, The method further includes: A cross-chain consensus request is sent to the business consensus node of the second business branch chain; wherein the cross-chain consensus request carries the block identifier of the cross-chain business block; the cross-chain consensus request is used to request the business consensus node of the second business branch chain to obtain the cross-chain business block from the first cross-chain storage space based on the block identifier, and to perform cross-chain consensus on the cross-chain business block.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Initial consensus is reached on the cross-chain business blocks; If the initial consensus result indicates that the cross-chain business block consensus has passed, then the steps of pre-committing the cross-chain business block based on the first business branch chain and storing the cross-chain business block in the first cross-chain storage space are executed.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: The system receives permission revocation indication information sent by the main chain consensus node; wherein, the permission revocation indication information is used to instruct the main chain consensus node to revoke the first consensus node's access permission to the second cross-chain storage space; the permission revocation indication information is generated by the main chain consensus node when it detects that the access permission revocation conditions are met, and the access permission revocation conditions include: the validity period of the access permission has been reached, or the relevant processing of the cross-chain business block has been completed, or the validity period of the access permission has been reached and the relevant processing of the cross-chain business block has been completed.

7. A blockchain-based block processing method, characterized in that, The blockchain includes a main business chain, a first business branch chain, and a second business branch chain. The first business branch chain corresponds to a first cross-chain storage space, and the second business branch chain corresponds to a second cross-chain storage space. The main chain consensus node of the main business chain allocates access permissions to the second cross-chain storage space to the first consensus node of the first business branch chain, and allocates access permissions to the first cross-chain storage space to the second consensus node of the second business branch chain. The method includes: Obtain cross-chain business blocks from the first cross-chain storage space; wherein, the cross-chain business blocks are generated and stored in the first cross-chain storage space by the first consensus node for the target business when the target business meets the cross-chain consensus conditions; Perform cross-chain consensus on the cross-chain business blocks to determine the cross-chain consensus result; A cross-chain consensus block is generated based on the cross-chain consensus result, and the cross-chain consensus block is pre-committed based on the second business branch chain; The cross-chain consensus block is stored in the second cross-chain storage space so that the first consensus node can retrieve the cross-chain consensus block from the second cross-chain storage space. Based on the cross-chain consensus result extracted from the cross-chain consensus block, a first state declaration block is added after the cross-chain business block on the first business branch chain. The state of the block to be submitted to the business branch chain is pending. The first state declaration block is used to declare whether the cross-chain business block on the first business branch chain is valid or invalid. Obtain the first state declaration block stored by the first consensus node from the first cross-chain storage space; Based on the first state declaration block, a second state declaration block is added after the cross-chain consensus block on the second business branch chain. The second state declaration block is used to declare whether the cross-chain consensus block on the second business branch chain is valid or invalid.

8. The method as described in claim 7, characterized in that, The method further includes: Receive a cross-chain consensus request sent by the first consensus node; wherein the cross-chain consensus request carries the block identifier of the cross-chain business block; In response to the cross-chain consensus request, the cross-chain business block is obtained from the first cross-chain storage space based on the block identifier.

9. The method as described in claim 7, characterized in that, The method further includes: The system receives permission revocation indication information sent by the main chain consensus node; wherein the permission revocation indication information is used to instruct the main chain consensus node to revoke the second consensus node's access permission to the first cross-chain storage space; the permission revocation indication information is generated by the main chain consensus node when it detects that the access permission revocation conditions are met, and the access permission revocation conditions include: the validity period of the access permission has been reached, or the relevant processing of the cross-chain business block has been completed, or the validity period of the access permission has been reached and the relevant processing of the cross-chain business block has been completed.

10. A blockchain-based block processing device, characterized in that, It includes units for implementing the blockchain-based block processing method as described in any one of claims 1-6, or units for implementing the blockchain-based block processing method as described in any one of claims 7-9.

11. A computer device, characterized in that, include: The system includes a processor, a communication interface, and a memory, which are interconnected. The memory stores executable program code, and the processor is used to call the executable program code to implement the blockchain-based block processing method as described in any one of claims 1-6, or to implement the blockchain-based block processing method as described in any one of claims 7-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a computer, cause the computer to implement the blockchain-based block processing method as described in any one of claims 1-6, or to implement the blockchain-based block processing method as described in any one of claims 7-9.

13. 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 blockchain-based block processing method as described in any one of claims 1-6, or implement the blockchain-based block processing method as described in any one of claims 7-9.

Images