Cross-blockchain transaction processing method and device, smart device, medium and product

Abstract

The embodiment of the application discloses a cross-blockchain processing method and device of a transaction, an intelligent device, a medium and a product. The method comprises the following steps: in response to a detected transaction transfer event of transferring a target transaction from a first business branch chain to a second business branch chain, a pre-transfer block is generated for the target transaction in the first business branch chain; a pre-transfer request is sent to a target consensus node of the second business branch chain based on the pre-transfer block; a feedback message returned by the target consensus node according to a pre-reception result is received, and an already-transferred block corresponding to the target transaction is generated in the first business branch chain after the feedback message is verified successfully; and an already-transferred notification is sent to the target consensus node according to the already-transferred block. The embodiment of the application can realize cross-chain transfer of the target transaction between different business branch chains.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to the field of blockchain, and particularly to a cross-blockchain transaction processing method, a cross-blockchain transaction processing device, a smart device, a computer-readable storage medium, and a computer program product. 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 different blockchains to store data from different business types; for example, different business branch chains can be used to store data corresponding to different business types. Therefore, how to achieve cross-chain data transfer between business branch chains has become a hot research topic. Summary of the Invention

[0003] This application provides a cross-blockchain processing method and related apparatus for transactions, which can realize the cross-chain transfer of target transactions between different business branch chains.

[0004] On one hand, embodiments of this application provide a method for cross-blockchain transaction processing, the method comprising: In response to a detected transaction transfer event that moves the target transaction from the first business branch chain to the second business branch chain, a pre-transfer block is generated for the target transaction in the first business branch chain; Based on the pre-transfer block, a pre-transfer request is sent to the target consensus node where the second business branch chain is located. The pre-transfer request is used to request the target consensus node to generate the pre-receive result of the target transaction in the second business branch chain. Receive feedback messages returned by the target consensus node based on the pre-received results, and after successfully verifying the feedback messages, generate the corresponding circulated block of the target transaction in the first business branch chain; Based on the already circulated blocks, a circulation notification is sent to the target consensus node. The circulation notification is used to notify the target consensus node to generate an operable block for the target transaction in the second business branch chain.

[0005] On the other hand, embodiments of this application provide a cross-blockchain transaction processing method, the method comprising: Receive the pre-transfer request sent by the source consensus node. The pre-transfer request is used to request the generation of the pre-received result of the target transaction in the second business branch chain. If the target transaction is successfully verified in response to the pre-transfer request, a pre-received result is generated for the target transaction. Return a feedback message generated based on the pre-received result to the source consensus node, so that the source consensus node can generate the transferred block corresponding to the target transaction in the first business branch chain contained in the source consensus node according to the feedback message; In response to the circulation notification returned by the source consensus node, an operable block for the target transaction is generated in the second business branch chain. The circulation notification is returned by the source consensus node based on the circulation block and is used to notify the generation of an operable block for the target transaction in the second business branch chain.

[0006] On the other hand, embodiments of this application provide a cross-blockchain transaction processing apparatus, the apparatus comprising: The processing unit is used to generate a pre-transfer block for the target transaction in the first business branch chain in response to a detected transaction transfer event that transfers the target transaction from the first business branch chain to the second business branch chain. The communication unit is used to send a pre-transfer request to the target consensus node where the second business branch chain is located based on the pre-transfer block. The pre-transfer request is used to request the target consensus node to generate the pre-received result of the target transaction in the second business branch chain. The processing unit is also used to receive feedback messages returned by the target consensus node based on the pre-received results, and after successfully verifying the feedback messages, to generate the transferred blocks corresponding to the target transaction in the first business branch chain; The communication unit is also used to send a circulation notification to the target consensus node based on the circulation block. The circulation notification is used to notify the target consensus node to generate an operable block for the target transaction in the second business branch chain.

[0007] In one implementation, the processing unit, when receiving the feedback message returned by the target consensus node based on the pre-received result, is specifically used for: Within the first timeout period after sending the pre-transfer request, check whether a feedback message has been received from the target consensus node based on the pre-received result; If a feedback message is received within the first timeout waiting period, the status of the target transaction on the second business branch chain is verified based on the feedback message to obtain the pre-receive verification result.

[0008] In one implementation, the pre-received result includes: the state information of the target transaction in the second business branch chain, and the pre-received signature information corresponding to the target transaction. The pre-received signature information is generated by the target consensus node signing the target transaction using its private key. The processing unit is used to verify the state of the target transaction on the second business branch chain based on the feedback message. When obtaining the pre-received verification result, it is specifically used for: Obtain the public key of the target consensus node; The public key of the target consensus node is used to verify the pre-received signature information to obtain the verification result. A pre-receive verification result is generated based on the status information and the signature verification result; wherein, when the status information indicates that the target transaction is in the pre-receive state in the second business branch chain, and the signature verification result indicates that the signature verification of the pre-received signature information is successful, the pre-receive verification result indicates that the pre-received result verification is successful.

[0009] In one implementation, the processing unit is further used for: In response to the detected state rollback condition for the target transaction, a first state rollback process is performed on the target transaction in the first business branch chain. The first state rollback process includes: setting the state of the target transaction in the first business branch chain to an operable state. The state rollback condition includes: not receiving the pre-received result within the first timeout waiting period, or receiving the pre-received result within the first timeout waiting period and failing to verify the pre-received result. Based on the target transaction that is in an operable state after state rollback processing, an operable block is generated and stored in the first business branch chain.

[0010] In one implementation, the processing unit, when generating a pre-transfer block for the target transaction in the first business branch chain, specifically performs the following functions: In the first business branch chain, the target transaction is pre-transfer processed. The pre-transfer process includes setting the state of the target transaction in the first business branch chain to the pre-transfer state. Sign the target transaction that is in the pre-transfer state after pre-transfer processing to generate pre-transfer signature information; The target transaction and pre-transfer signature information in the pre-transfer state are packaged and processed to generate a pre-transfer block.

[0011] In one implementation, the pre-transfer state of the target transaction in the first business branch chain is locked. Once locked, the target transaction cannot be transferred to the third business branch chain, which is different from the second business branch chain.

[0012] In one implementation, the methods for determining whether a transaction transition event has been detected include: When a transaction transfer request for a target transaction is received forwarded by the routing proxy network, a transaction transfer event is determined to have been detected. The routing proxy network is a blockchain network, which includes a witness subnetwork and a consensus subnetwork. The witness subnetwork includes one or more business nodes, and the consensus subnetwork includes one or more consensus nodes. The routing proxy node is used to isolate the witness subnetwork and the consensus subnetwork. Alternatively, the lifecycle of a target transaction in an operable state in the first business branch chain is detected, and a transaction transition event is determined to have been detected when the transaction transition conditions are met.

[0013] On the other hand, embodiments of this application provide a cross-blockchain transaction processing apparatus, the apparatus comprising: The receiving unit is used to receive the pre-transfer request sent by the source consensus node. The pre-transfer request is used to request the generation of the pre-received result of the target transaction in the second business branch chain. The processing unit is used to generate a pre-received result for the target transaction if the target transaction is successfully verified in response to the pre-transfer request. The processing unit is also used to return a feedback message generated based on the pre-received result to the source consensus node, so that the source consensus node can generate the transferred block corresponding to the target transaction in the first business branch chain contained in the source consensus node based on the feedback message; The processing unit is also configured to generate an operable block of the target transaction in the second business branch chain in response to the circulation notification returned by the source consensus node. The circulation notification is returned by the source consensus node based on the circulation block and is used to notify the generation of an operable block of the target transaction in the second business branch chain.

[0014] In one implementation, the processing unit is further used for: Within the second timeout period after sending the feedback message, check whether a notification of completed transfer has been received from the source consensus node; If no feedback notification is received from the source consensus node within the second timeout waiting period, then obtain the access period for accessing the source consensus node; At each access cycle, an access request is sent to the source consensus node. The access request is used to request the source consensus node to return a notification that the data has been transferred, until the source consensus node returns the notification that the data has been transferred.

[0015] In one implementation, the processing unit, when generating a pre-received result for the target transaction in the second business branch chain, specifically performs the following: Set the target transaction's status to the pre-receive state on the second business branch chain; Sign the target transaction in the pre-received state to obtain the pre-received signature information; The target transaction and pre-received signature information in the pre-received state are packaged and processed to generate the pre-received result.

[0016] In one implementation, when the target transaction is in the pre-receive state on the second business branch chain, the transaction information of the target transaction cannot be used. Use includes: access, processing, and transfer.

[0017] On the other hand, embodiments of this application provide a smart device, the device comprising: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program that, when executed by a processor, implements the cross-blockchain processing method for transactions as described above.

[0018] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted for loading by a processor and executing a cross-blockchain processing method for transactions as described above.

[0019] On the other hand, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a cross-blockchain processing device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the cross-blockchain processing device to perform the aforementioned cross-blockchain transaction processing method.

[0020] In this embodiment, in response to a detected transaction transfer event that moves a target transaction from a first business branch chain to a second business branch chain, the target transaction can be transferred from the first business branch chain to the second business branch chain, enabling cross-chain transfer of the target transaction between different business branch chains. Furthermore, during each step of the target transaction transfer process, a corresponding transfer state (such as pre-transfer state, pre-receive state, and transferred state) is set for the target transaction on the business branch chain. For example, during cross-chain transfer, the target transaction is first set from the operable state to the pre-receive state in the first business branch chain to indicate that the target transaction is ready to transfer to the second business branch chain. Then, the state of the target transaction is set to the pre-receive state on the second business branch chain to indicate that the second business branch chain is ready to receive the target transaction, and so on. This ensures the consistency of the target transaction's state changes during the transfer process and guarantees the uniqueness and security of the target transaction's operation during the transfer process. Attached Figure Description

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

[0022] Figure 1a This application illustrates a schematic diagram of the structure of a blockchain provided in an exemplary embodiment. Figure 1bThis application shows a schematic diagram of the structure of a blockchain network provided in an exemplary embodiment; Figure 1c This illustration shows a schematic diagram of a tree-like chain structure provided in an exemplary embodiment of this application; Figure 1d This application shows a schematic diagram of the structure of a blockchain network provided in an exemplary embodiment; Figure 1e This illustration shows a schematic diagram of a cross-chain transfer process of a target transaction from a first business branch chain to a second business branch chain, provided by an exemplary embodiment of this application. Figure 2 A flowchart illustrating a cross-blockchain transaction processing method provided in an exemplary embodiment of this application is shown. Figure 3 This illustration shows a schematic diagram of generating a pre-transfer block for a target transaction on a first business branch chain in response to a transaction transfer event, according to an exemplary embodiment of this application. Figure 4 This illustration shows a schematic diagram of a target transaction state rollback on a first business branch chain, provided by an exemplary embodiment of this application. Figure 5 A flowchart illustrating a cross-blockchain transaction processing method provided in an exemplary embodiment of this application is shown. Figure 6 This illustration shows a schematic diagram of generating a pre-receive block for a target transaction on a second service branch chain in response to a pre-receive result, according to an exemplary embodiment of this application. Figure 7 This illustration shows a schematic diagram of a target consensus node periodically accessing a source consensus node, provided by an exemplary embodiment of this application. Figure 8 This 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 10a This illustration shows a schematic diagram of the architecture of a two-layer blockchain network provided in an exemplary embodiment of this application; Figure 10b This illustration shows a flowchart of a cross-blockchain processing method under a two-layer blockchain network provided by an exemplary embodiment of this application; Figure 11 This invention provides a schematic diagram of the structure of a cross-blockchain transaction processing apparatus according to an exemplary embodiment of the present application. Figure 12This invention provides a schematic diagram of the structure of a cross-blockchain transaction processing apparatus according to an exemplary embodiment of the present application. Figure 13 A schematic diagram of the structure of a smart device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0023] 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 skilled in the art without creative effort are within the scope of protection of this application.

[0024] 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 1a ,like Figure 1a 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.

[0025] 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 1b ;like Figure 1bAs 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

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

[0027] 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 business, credit investigation business, profit and loss business, enterprise qualification business, and tax refund business, etc. To facilitate better management of business data corresponding to different business types, a blockchain can be created for each business type to store the corresponding business data, facilitating the supervision and maintenance of business data corresponding to different business types. However, in practice, it has been found that when multiple blockchains are maintained in a blockchain network, there is often a need for cross-chain transfer of transactions stored in one blockchain to another. Here, a transaction can be simply understood as transaction data or business data. The cross-chain transfer of transactions refers to the process of transferring transaction information (such as identifiers used to identify transactions, transaction description information, summary information generated based on the target transaction, etc.) and operation permissions that can operate on the transaction (such as access, download, transfer, etc.) from one blockchain to another. For example, in a tax scenario involving cross-chain transaction requirements, suppose the blockchain network corresponding to the tax scenario maintains a first business branch chain for credit reporting and a second business branch chain for invoicing. Suppose that issuing an invoice to a target user (such as any user with an invoicing requirement) requires the target user's credit certificate. In response to the target user's invoicing request, the target user's credit certificate is first issued on the first business branch chain. After the target user's credit certificate is issued, it needs to be transferred to the second business branch chain (such as a certificate used to prove the target user's credit) so that the second business branch chain can issue an invoice based on the target user's credit certificate.

[0028] To enable cross-chain transaction transfer between different business branch chains, this application proposes a cross-blockchain transaction processing scheme. In response to a transaction transfer event where a target transaction (such as any transaction) is transferred from a first business branch chain to a second business branch chain, the scheme first sets the target transaction to a pre-transfer state in the first business branch chain, indicating that the target transaction is ready to be transferred to the second business branch chain. Then, a pre-transfer request is sent to the second business branch chain, requesting the second business branch chain to pre-receive the target transaction. When the first business branch chain knows from the pre-receive result returned by the second business branch chain that the second business branch chain is ready to receive the target transaction, the first business branch chain sets the target transaction to a transferred state, indicating that the target transaction and the operational permissions to operate on the target transaction have been transferred to the second business branch chain. The second business branch chain then sets the target transaction to an operable state. Thus, when other business branch chains want to transfer the target transaction, they can only obtain it from the second business branch chain, and not from the first business branch chain. Through the aforementioned transfer steps performed on the target transaction, the target transaction and the operation permissions that can operate on the target transaction can be transferred from the first business branch chain to (or transferred to) the second business branch chain, realizing the cross-chain transfer of the target transaction between different business branch chains; and by setting the corresponding state of the target transaction (such as pre-transfer state, pre-receive state, and transferred state) in each transfer step, the consistency of the state changes of the target transaction during the transfer process is maintained, and the uniqueness and security of the target transaction being operated on during the transfer process are ensured.

[0029] It should be noted that the embodiments of this application support multi-level transfer of the target transaction, that is, the transaction transfer event can instruct the target transaction to be transferred to at least two business branch chains simultaneously. For example, if the target transaction is stored in business branch chain 1, and it is desired to transfer the target transaction to business branch chain 2 and business branch chain 3 simultaneously, after setting the target transaction to a pre-transfer state in business branch chain 1, a pre-transfer request generated based on the target transaction in the pre-transfer state can be sent simultaneously to target consensus node A where business branch chain 2 is located, and target consensus node B where business branch chain 3 is located; and target consensus node A and target consensus node B set the state of the target transaction to a pre-receive state in their respective business branch chains. If the source consensus node receives feedback message 1 returned by target consensus node B based on the pre-receive result within a certain time period, but does not receive feedback message 2 returned by target consensus node C based on the pre-receive result, then the source consensus node can generate a block indicating that the target transaction failed to transfer to business branch chain 3 in business branch chain 1, but the source consensus node still executes the process of transferring the target transaction to business branch chain 2. Based on this, the target transaction may be simultaneously transferred to both business branch chain 2 and business branch chain 3, indicating that both business branch chain 1 and business branch chain 3 have operational permissions for the target transaction; of course, the target transaction may also be successfully transferred only to business branch chain 2 or business branch chain 3. This application embodiment does not limit the number of transfer levels of the target transaction (i.e., the number of business branch chains to receive the target transaction). The above description uses transfer levels of 1 and 2 as examples and does not limit the cross-blockchain solution provided in this application embodiment. For ease of explanation, the following description will use the example of transferring the target transaction from the first business branch chain to a second business branch chain.

[0030] It should also be noted that the cross-blockchain solution proposed in this application can be applied to tree-structured chains. A tree-structured chain can be simply understood as a blockchain structure resembling a tree, formed by a main business chain (or base sub-chain) and one or more business branch chains derived from (or forked from) the main business chain. A schematic diagram of an exemplary tree-structured chain can be found here. Figure 1c ,like Figure 1cAs shown, the tree-structured chain 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 described below: ① The main business chain 103 can include the registration information of each business branch chain. The registration information of the business branch chain 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, etc. The chain identifier is a unique identifier for the business branch chain, which allows the business branch chain to be quickly located in the blockchain network. The business description information describes the relevant information of the business corresponding to the business branch chain, such as the business type, business data format, business verification method, etc. The node identifier of the supervisory node refers to the node identifier of the consensus node that has the authority to supervise the business branch chain (such as consensus, storage, etc.). Of course, depending on the actual application scenario, the registration information of the business branch chain may include other information besides the above description. This embodiment of the application does not limit the registration information of the business branch chain. ② 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 1c 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 1cAssuming 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 1d 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 1dAs 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 core consensus nodes for maintaining the main business chain. Any core 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. Any 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 the business branch chains can refer to the authority to reach consensus on unverified blocks to be stored in the business branch chains, etc. It should be noted that core consensus nodes can also maintain all or part of the business branch chains. This application embodiment does not limit this. In addition to maintaining the business branch chains within the 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-related scenario. Assuming the tax scenario involves invoice and credit reporting, and the State Taxation Administration has oversight authority over all tax-related businesses, then the devices used by the State Taxation Administration can connect to the main chain consensus cluster in the blockchain network. For instance, the devices used by the State Taxation Administration can serve as core consensus nodes within the main chain consensus cluster. Similarly, devices used by the tax bureau with oversight authority over invoice-related businesses can connect to the branch chain consensus cluster "Invoice Consensus Cluster," and devices used by the tax bureau with oversight authority over credit reporting businesses 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 the 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] Based on the tree-like chain structure described above, the first business branch chain and the second business branch chain mentioned in the embodiments of this application can refer to two different business branch chains derived from the main business chain. In the tree-like chain structure, the cross-chain transfer process of the target transaction from the first business branch chain to the second business branch chain proposed in the embodiments of this application can be found in [reference needed]. Figure 1e ,like Figure 1e As shown, assuming the target transaction is in an operable state in business branch chain 1031 (i.e., the first business branch chain), the operable state means that when the target transaction is in an operable state, it supports being transferred to other business branch chains, and the transaction transfer event indicates that the target transaction should be transferred from business branch chain 1031 (i.e., the first business branch chain) to business branch chain 1032 (i.e., the second business branch chain). In response to the transaction transfer event, the target transaction can be modified from the operable state to the pre-transfer state in business branch chain 1031. The pre-transfer state means that the target transaction is ready to be transferred to business branch chain 1032, and a pre-transfer block B6 is generated.

[0038] Business branch chain 1031 (specifically, the business consensus node where business branch chain 1031 is located, referred to as the "source consensus node" in this embodiment) sends a pre-transfer request to business branch chain 1032 (specifically, the business consensus node where business branch chain 1032 is located, referred to as the "target consensus node" in this embodiment) based on the pre-transfer block; the target consensus node responds to the pre-transfer request and generates a pre-receive block for the target transaction in business branch chain 1032. At this time, the target transaction is in the pre-receive state in business branch chain 1032. The so-called pre-receive state means that business branch chain 1032 has received the target transaction, but does not have the right to use the target transaction. That is, when the target transaction is in the pre-receive state on business branch chain 1032, the transaction information of the target transaction cannot be used. This use includes: access, processing, transfer, etc.; then the target consensus node returns the pre-receive result to the source consensus node based on the pre-receive block.

[0039] After the source consensus node successfully verifies the pre-received result, it generates a transferred block for the target transaction in business branch chain 1031. At this time, the target transaction is in the received state in business branch chain 1031, indicating that the transaction information of the target transaction and the operation permission to operate the target transaction have been transferred to the target consensus node. Business branch chain 1031 no longer has the permission to transfer the target transaction. The source consensus node then sends a transferred notification to the target consensus node based on the transferred block, so that the target consensus node can generate an operable block for the target transaction in business branch chain 1032 based on the transferred notification, indicating that business branch chain 1032 has successfully received the target transaction and the operation permission to operate the target transaction.

[0040] The above example uses a tree-structured blockchain to briefly illustrate the process of the cross-blockchain processing scheme proposed in this application. It is understood that when the blockchain structure is not a tree-structured blockchain, such as when the first business branch chain and the second business branch chain are independent blockchains rather than two blockchains linked to the main business chain, it will not affect or limit the cross-blockchain processing scheme proposed in this application. This is hereby stated.

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

[0042] Figure 2 The illustration shows a flowchart of a cross-blockchain transaction processing method provided by an exemplary embodiment of this application; the cross-blockchain processing method can be executed by a source consensus node with regulatory authority over a first business branch chain; the cross-blockchain processing method may include, but is not limited to, steps S201-S204: S201: In response to a detected transaction transfer event that moves the target transaction from the first business branch chain to the second business branch chain, a pre-transfer block is generated for the target transaction in the first business branch chain.

[0043] A transaction transfer event may carry: the chain identifier of the first business branch chain where the target transaction is in an operable state, and the chain identifier of the second business branch chain to receive the target transaction. The transaction transfer event is used to trigger the transfer of the target transaction (such as its transaction information) and the operational permissions (such as transfer) to the second business branch chain from the first business branch chain. The method for determining whether a transaction transfer event has been detected may include: detecting the lifecycle of the target transaction in an operable state in the first business branch chain; and determining that a transaction transfer event has been detected when the transaction transfer conditions are met. The definition and length of the target transaction's lifecycle, as well as the corresponding transaction transfer conditions, vary depending on the specific content of the target transaction. For example, in a tax scenario, assuming the target transaction is an invoicing transaction, the corresponding transaction transfer condition is: the first business branch chain completes the invoicing. The length of the target transaction's lifecycle in the first business branch chain may include: the time elapsed from when the first business branch chain receives the target transaction until the first business branch chain completes the invoicing. Of course, the transaction flow conditions and lifecycle of the target transaction can also be set by business personnel according to business needs, which satisfies the business personnel's custom setting needs for the target transaction; the embodiments of this application do not limit the transaction flow conditions and lifecycle corresponding to the target transaction.

[0044] In its implementation, in response to a transaction transfer event that moves a target transaction from the first business branch chain to the second business branch chain, the source consensus node first performs pre-transfer processing on the target transaction in the first business branch chain. This pre-transfer processing includes setting the state of the target transaction in the first business branch chain to a pre-transfer state, i.e., modifying the target transaction from an operable state to a pre-transfer state in the first business branch chain. Setting or modifying the state of the target transaction can be simply described as assigning a state tag to the target transaction to indicate its current state. Secondly, the target transaction in the pre-transfer state after pre-transfer processing is signed to generate pre-transfer signature information. Specifically, the source consensus node can obtain its own node private key and use it to sign the target transaction in the pre-transfer state to obtain the pre-transfer signature information. Finally, the target transaction in the pre-transfer state and the pre-transfer signature information are packaged together to obtain a pre-transfer block. It is worth noting that the above is only an exemplary implementation of generating pre-circulation blocks. In other implementations, the node certificate corresponding to the source consensus node can also be packaged into the pre-circulation block to prove the node identity of the source consensus node. The so-called node certificate can be issued by an organization with certificate issuance authority, which includes Public Key Infrastructure (PKI), and can bind the relevant key pairs and the identity of the certificate holder to provide users with convenient related certificate management functions.

[0045] An exemplary flowchart illustrating the process of generating a pre-transfer block for a target transaction on the first business branch chain in response to a transaction transfer event can be found here. Figure 3 ,like Figure 3 As shown, in response to a transaction transfer event that moves the target transaction from the first business branch chain 1031 to the second business branch chain, the source consensus node 301 adjusts the target transaction from the operable state to the pre-transfer state in the first business branch chain 1031 and generates a pre-transfer block B7. When all or some of the business consensus nodes in the sub-chain consensus cluster maintaining the first business branch chain 1031 successfully verify the consensus of the pre-transfer block B7, the pre-transfer block B7 is stored in the first business branch chain 1031. Specifically, the pre-transfer block B7 can be connected after the operable block B6.

[0046] Among them, all or part of the business consensus nodes contained in the sub-chain consensus cluster that maintains the first business branch chain 1031 can call consensus algorithms to realize consensus verification of pre-transfer blocks; several exemplary consensus algorithms are given below: 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.

[0047] 2) PoS (proof-of-stake) is an upgraded consensus mechanism of Proof-of-Work; electronic resources can refer to resources stored in electronic accounts in electronic form and that can be circulated through the Internet.

[0048] 3) DPoS (Delegated Proof of Stake) is a stake-based proof-of-stake mechanism similar to board voting, where holders of electronic resources vote for a certain number of nodes, which act as their proxies for verification and record-keeping.

[0049] 4) PBFT (Practical Byzantine Fault Tolerance) is a message-passing-based consensus algorithm that achieves consensus through three phases, which may be repeated due to failure.

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

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

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

[0053] Through the above implementation process, the source consensus node can adjust the target transaction from an operational state to a pre-transfer state in the first business branch chain, indicating that the target transaction is ready to be transferred to the second business branch chain. Furthermore, the pre-transfer state of the target transaction in the first business branch chain is locked, and the locked target transaction cannot be transferred to the third business branch chain, which is different from the second business branch chain. This method, which only requires locking the state of the target transaction (such as the pre-transfer state) before and after its transfer, ensures the consistency of the target transaction's state during the transfer process, avoiding the need for a third-party central service to control and manage the state of the target transaction during the transfer process, thus improving transaction transfer efficiency.

[0054] S202: Send a pre-transfer request to the target consensus node where the second business branch chain is located based on the pre-transfer block.

[0055] Specifically, after generating a pre-transfer block for the target transaction on the first business branch chain, a pre-transfer request can be generated based on the pre-transfer block. This pre-transfer request can carry the proof message of the pre-transfer block, the transaction information of the target transaction, etc. This pre-transfer request is used to request the target consensus node to generate a pre-received result of the target transaction on the second business branch chain. In this way, the target consensus node can respond to the pre-transfer request, perform cross-chain verification of the pre-transfer block, obtain the transaction information of the target transaction after successful verification, generate a pre-received block for the target transaction on the second business branch chain, and then generate a feedback message based on the pre-received block.

[0056] S203: Receive the feedback message returned by the target consensus node based on the pre-received result, and after successfully verifying the pre-received result, generate the corresponding transferred block of the target transaction in the first business branch chain.

[0057] The feedback message returned by the target consensus node carries a pre-received result, which includes: the state information of the target transaction in the second business branch chain, and the pre-received signature information corresponding to the target transaction. The pre-received signature information is generated by the target consensus node signing the target transaction using its private key. When the source consensus node receives the feedback message returned by the target consensus node based on the pre-received result, the source consensus node can verify the pre-received result. Specifically, it verifies the state of the target transaction on the second business branch chain according to the feedback message, and upon successful verification, generates a circulated block for the target transaction in the first business branch chain. It should be noted that the specific implementation of generating a circulated block for the target transaction in the first business branch chain can be found in the aforementioned description of the specific implementation of generating a pre-circulated block for the target transaction in the first business branch chain; the only difference here is that the state of the target transaction is changed from a pre-circulated state to a circulated state.

[0058] An exemplary implementation process for verifying the status of the target transaction on the second business branch chain based on feedback messages may include: ① Obtaining the public key of the target consensus node, such as obtaining the public key of the target consensus node from the target consensus node itself, or obtaining the historically stored public key of the target consensus node from the database of the source consensus node. ② Using the public key of the target consensus node, verifying the pre-received signature information to obtain the verification result; the specific verification process can be summarized as follows: using the public key of the target consensus node to decrypt the pre-received signature information to obtain the digest information of the target transaction, then using the same digest generation algorithm as the target consensus node (such as Message Digest (MD), Secure Hash Algorithm (SHA), Message Authentication Code (MAC)) to generate the digest information of the target transaction, and then comparing whether the decrypted digest information of the target transaction is the same as the generated digest information of the target transaction. If they are the same, the verification result is determined to be successful; otherwise, the verification result is determined to be unsuccessful. ③ Generate a pre-receive verification result based on the status information and the signature verification result. When the status information indicates that the target transaction is in the pre-receive state in the second business branch chain, and the signature verification result indicates that the signature verification of the pre-received signature information is successful, the pre-receive verification result indicates that the pre-received result is verified successfully. When the status information indicates that the target transaction is not in the pre-receive state in the second business branch chain, or when the signature verification result indicates that the signature verification of the pre-received signature information fails, the pre-receive verification result is determined to be verified successfully.

[0059] It should be noted that this application embodiment also introduces a timeout rollback mechanism during the change of the target transaction's transfer status, which makes the cross-chain transfer process of the transaction more fault-tolerant and robust, facilitating the transfer of transactions in more complex or heterogeneous blockchain network scenarios. The so-called timeout rollback mechanism refers to a mechanism that starts a timeout wait after the source consensus node sends a pre-transfer request, and executes subsequent operations based on whether a feedback message is received from the target consensus node within the timeout wait period.

[0060] The following describes the process by which the source consensus node receives the feedback message returned by the target consensus node based on the pre-received result after the introduction of the timeout rollback mechanism. Specifically, within the first timeout waiting period after sending the pre-transfer request, it checks whether the feedback message returned by the target consensus node based on the pre-received result has been received; if the feedback message is received within the first timeout waiting period, the status of the target transaction on the second business branch chain is verified based on the feedback message to obtain the pre-received verification result. Similarly, if the target transaction is detected to meet the state rollback condition, the state rollback condition includes: if no feedback message is received within the first timeout waiting period after sending the pre-transfer request, then in response to the detected state rollback condition for the target transaction, the target transaction in the first business branch chain is subjected to state rollback processing; the state rollback processing includes: setting the state of the target transaction in the first business branch chain to an operable state; in other words, when no feedback message is received within the first timeout waiting period, the target transaction is subjected to state rollback processing on the first business branch chain, and an operable block is generated based on the target transaction that is in an operable state after the state rollback processing, and the operable block is stored in the first business branch chain, indicating that the cross-chain transfer of the target transaction from the first business branch chain to the second business branch chain has failed.

[0061] There are many reasons why the target consensus node might not return a feedback message to the source consensus node within the first timeout period. For example, the communication connection between the target and source consensus nodes might be lost; or the target consensus node might fail to set the pre-receive state of the target transaction due to its own reasons (such as equipment failure), etc. This application embodiment does not limit these reasons. In addition, the state rollback condition may also include: receiving a feedback message within the first timeout period and failing to verify the feedback message (such as verifying that the state of the target transaction in the second business branch chain is not the pre-receive state). In this implementation, the source consensus node also performs state rollback processing on the target transaction in the first business branch chain, which will not be elaborated here.

[0062] For example, assuming the first timeout period set for the source consensus node is 2 hours, the timer starts after the source consensus node sends a pre-transfer request. If, after 1.5 hours, a feedback message is detected from the target consensus node based on the pre-received result, it indicates that the target consensus node returned a feedback message within the first timeout period, triggering the execution of steps responding to the continuous transfer condition. Conversely, if, after 2 hours, no feedback message is detected from the target consensus node based on the pre-received result, it indicates that the target consensus node did not return a feedback message within the first timeout period, determining that a state rollback condition for the target transaction has been detected, triggering the execution of steps responding to the state rollback condition. An exemplary process for the state rollback of a target transaction on the first business branch chain can be found in [link to relevant documentation]. Figure 4 ,like Figure 4 As shown, after the source consensus node 301 sends a pre-transfer request to the target consensus node 302, if it does not receive a feedback message from the target consensus node 302 within the first timeout waiting period, the source consensus node 301 sets the state of the target transaction to an operable state and generates an operable block B8 of the target transaction in the first business branch chain 1031, indicating that the state of the target transaction in the first business branch chain 1031 is rolled back to the operable state.

[0063] S204: Send a notification of the completed block to the target consensus node.

[0064] The "transfer completed" notification is used to inform the target consensus node to generate an operable block for the target transaction in the second business branch chain. After receiving the "transfer completed" notification from the source consensus node, the target consensus node performs cross-chain verification of the target transaction in the first business branch chain based on the notification. Upon successful verification, it generates an operable block for the target transaction in the second business branch chain; this transfers the target transaction from the first to the second business branch chain. If other business branch chains subsequently wish to transfer the target transaction, they must request the transfer from the second business branch chain.

[0065] In this embodiment, the target transaction and the operation permissions that can operate on the target transaction can be transferred from the first business branch chain to (or transferred to) the second business branch chain, realizing the cross-chain transfer of the target transaction between different business branch chains; and, by setting the corresponding state of the target transaction (such as pre-transfer state, pre-receive state, and transferred state, etc.) in each step of the transfer, the consistency of the state change of the target transaction during the transfer process is maintained, and the uniqueness and security of the target transaction being operated on during the transfer process are ensured.

[0066] Figure 5The illustration shows a flowchart of a cross-blockchain transaction processing method provided by an exemplary embodiment of this application; the cross-blockchain processing method can be executed by a target consensus node with supervisory authority over a second business branch chain; the cross-blockchain processing method may include, but is not limited to, steps S501-S504: S501: Receive the pre-transfer request sent by the source consensus node.

[0067] S502: If the target transaction is successfully verified in response to the pre-transfer request, a pre-receive result is generated for the target transaction in the second business branch chain.

[0068] In steps S501-S502, the pre-transfer request sent by the source consensus node carries the transaction information of the target transaction. The pre-transfer request is used to request the generation of a pre-receipt result for the target transaction in the second business branch chain. When the target consensus node receives the pre-transfer request, it can perform cross-chain verification of the target transaction in response to the pre-transfer request, and generate a pre-receipt result for the target transaction in the second business branch chain after successful verification. The pre-receipt result here may include a pre-receipt block generated for the target transaction in the second business branch chain, or a notification message generated based on the pre-receipt block, which indicates the status of the target transaction in the second business branch chain.

[0069] The specific implementation process of the target consensus node generating pre-received blocks on the second business branch chain can be found in [link to relevant documentation]. Figure 2 The specific implementation process for generating pre-circulated blocks or already-circulated blocks described in the illustrated embodiments is briefly explained here: On the second business branch chain, the state of the target transaction is set to the pre-receive state, indicating that the target consensus node is ready to receive the target transaction. The term "target consensus node ready to receive the target transaction" means that the target consensus node has obtained the target transaction (or the transaction information of the target transaction), but the target transaction is still in an unavailable state on the second business branch chain. In other words, when the target transaction is in the pre-receive state on the second business branch chain, the transaction information of the target transaction cannot be used. Use can include: access, processing (such as editing, updating, etc.), transfer, etc. Then, the target transaction in the pre-receive state is signed using the private key of the target consensus node to obtain pre-received signature information. Finally, the target transaction in the pre-received state and the pre-received signature information are packaged to generate a pre-received block. If the pre-received result is not a pre-received block, a pre-received result needs to be generated based on the pre-received block.

[0070] An exemplary diagram illustrating the generation of a pre-receive block for a target transaction on a second service branch chain in response to a pre-received result can be found here. Figure 6 ;like Figure 6As shown, after the target consensus node 302 responds to the received pre-transfer request, it first sets the target transaction to a pre-receive state, and then generates a pre-receive block C6 based on the target transaction in the pre-receive state. After the consensus node with consensus authority of the second business branch chain successfully verifies the consensus of the pre-receive block C6, it stores the pre-receive block C6 in the second business branch chain, such as connecting the pre-receive block C6 to block C5.

[0071] It is worth noting that the process by which the target consensus node responds to the pre-transfer request and performs cross-chain verification of the target transaction may include: verifying the state of the target transaction in the first business branch chain, and verifying whether the transfer of the target transaction meets the transfer requirements of the target consensus node. Specifically: ① The method of verifying the state of the target transaction in the first business branch chain may include: the pre-transfer request may carry the state information of the target transaction in the first business branch chain; when the state information indicates that the state of the target transaction in the first business branch chain is the pre-transfer state, it means that the target transaction has successfully transferred from the operable state to the pre-transfer state in the first business branch chain, and the state verification of the target transaction in the first business branch chain is determined to be successful; conversely, when the state information indicates that the state of the target transaction in the first business branch chain is the pre-transfer state, it means that the state transfer of the target transaction in the first business branch chain has failed, and the state verification of the target transaction in the first business branch chain has failed.

[0072] ② Verifying whether the flow of the target transaction meets the flow requirements of the target consensus node may include: verifying whether the recipient of the target transaction is the target consensus node. For example, the public key of the source consensus node can be used to verify the signature of the target transaction. When the signature verification is successful, it indicates that the target consensus node is the recipient of the target transaction; otherwise, the target consensus node is not the recipient of the target transaction. Alternatively, the legality of the target transaction can be verified. Legality verification may refer to: verifying whether the data format of the target transaction meets the data format requirements of the target consensus node; or verifying whether the target transaction is legal or ethically sound data; or verifying whether the sender of the target transaction complies with the rules; and so on. Of course, the above are just a few exemplary methods for verifying the target transaction. It is understood that the verification process for the target transaction may be different depending on different business needs. The specific verification process for the target transaction in this application embodiment is not limited, but is described here.

[0073] S503: Return a feedback message generated based on the pre-received results to the source consensus node.

[0074] After the target consensus node generates a pre-received block for the target transaction on the second business branch chain based on step S502, it can obtain a pre-received result based on the pre-received block and return a feedback message to the source consensus node according to the pre-received result. This feedback message is used to report the status of the target transaction on the second business branch chain. This allows the source consensus node to respond to the feedback message by generating a circulated block corresponding to the target transaction in the first business branch chain after successfully verifying the pre-received result, and returning a circulated notification based on the circulated block. The circulated notification is used to notify the generation of an operable block for the target transaction in the second business branch chain. It should be noted that the specific implementation of the source consensus node's response to the feedback message described above can be found in the aforementioned... Figure 2 The specific implementation details of step S203 in the illustrated embodiment will not be repeated here.

[0075] S504: In response to the flow notification returned by the source consensus node, generate an operable block for the target transaction in the second business branch chain.

[0076] Specifically, after receiving the notification that the transaction has been transferred, the target consensus node can verify the status of the target transaction on the first business branch chain in response to the notification. Specifically, it verifies whether the status of the target transaction on the first business branch chain is in the transferred state. After successfully verifying the status of the target transaction on the first business branch chain, the target transaction can be adjusted from the pre-received state to the operable state. The target transaction in the operable state can be transferred to other business branch chains. Then, based on the target transaction in the operable state, an operable block is generated for the target transaction on the second business branch chain.

[0077] It should be noted that the target consensus node in this embodiment, similar to the source consensus node, also supports a timeout rollback mechanism. The following describes the process by which the target consensus node receives the completed notification from the source consensus node after introducing the timeout rollback mechanism; wherein: within the second timeout waiting period after sending the feedback message, the target consensus node checks whether it has received the completed notification from the source consensus node. If the completed notification is received within the second timeout waiting period, the steps responding to the completed notification from the source consensus node are triggered. If the completed notification is not received within the second timeout waiting period, the target consensus node enters a slow wait state to periodically access the source consensus node to see if it has generated a completed notification for the pre-received result. The process by which the target consensus node enters a slow wait state to periodically access the source consensus node may include: obtaining an access period for accessing the source consensus node, which can be pre-set by business personnel according to business needs; sending an access request to the source consensus node according to the access period, which requests the source consensus node to return a completed notification, until the completed notification is received from the source consensus node. Of course, if the target consensus node periodically accesses the source consensus node within the preset time period, but still does not receive a notification of successful transfer from the source consensus node, then the target consensus node can end the cross-chain transfer process of transferring the target transaction from the first business branch chain to the second business branch chain, that is, the cross-chain transfer of the target transaction fails. The specific time length of the preset time period is not limited in this application embodiment. For example, the preset time period can be the sum of the time periods of 3 access cycles.

[0078] The following is combined with Figure 7 This section provides a brief overview of the process by which the target consensus node periodically accesses the source consensus node, such as... Figure 7 As shown, after the target consensus node 302 sends a feedback message to the source consensus node 301, it starts a timer. If the target consensus node 302 still has not received the completed transaction notification from the source consensus node 301 when the timer duration equals the second timeout waiting duration, the target consensus node 302 sends an access request to the source consensus node 301 every access cycle to request the source consensus node 301 to return the completed transaction notification. When the target consensus node 302 receives the completed transaction notification from the source consensus node, it verifies the status of the target transaction on the first business branch chain according to the completed transaction notification. If the verification result shows that the target transaction is in a completed transaction state on the first business branch chain, it generates an operable block C7 for the target transaction on the second business branch chain. After the consensus verification of the operable block C7 is successful, the operable block C7 is stored in the second business branch chain, thereby transferring the target transaction and the operation permissions that can operate the target transaction from the first business branch chain to the second business branch chain.

[0079] In this embodiment, in response to a transaction transfer event that moves a target transaction from a first business branch chain to a second business branch chain, the target transaction and the operational permissions enabling it can be transferred between different business branch chains, achieving cross-chain transfer of the target transaction. Furthermore, during the transfer of the target transaction, the state of the target transaction on the business branch chain is locked after each transfer step. For example, if the state of the target transaction is set to a pre-transfer state in the first business branch chain, the pre-transfer state is locked, preventing the target transaction in the pre-transfer state from transferring to other business branch chains (such as business branch chains different from the second business branch chain). This ensures the consistency of the target transaction's state changes and eliminates reliance on a third-party service center to control the cross-chain process, reducing the cost of cross-chain transaction transfer. Additionally, this embodiment introduces a timeout rollback mechanism to improve the fault tolerance and robustness of the cross-chain transaction transfer process, enabling the cross-blockchain processing solution provided by this embodiment to be applied to transaction transfers in more complex blockchain networks, thus improving the scalability of the corresponding application scenarios.

[0080] It is worth noting that blockchain networks can include single-layer, two-layer, or multi-layer networks. Here, "layer" refers to the number of sub-networks contained 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 1b The illustrated blockchain network is a single-layer blockchain network, in which secure access and data synchronization between blockchain nodes can be achieved through a consensus mechanism. In one implementation, the cross-blockchain processing method proposed in this application embodiment is applied to... Figure 1b In the single-layer blockchain network shown, under this implementation, the source consensus node and target consensus node mentioned in the embodiments of this application are consensus nodes belonging to the single-layer blockchain network.

[0081] In other implementations, the cross-blockchain processing method proposed in this application can be applied not only to the single-layer blockchain network described in the foregoing embodiments (such as a blockchain network containing only one blockchain), 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 common data peer-to-peer blockchain deployment method is not suitable when data involving personal privacy or national security is involved 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.

[0082] Figure 8 This application illustrates an exemplary embodiment of an architecture diagram of a two-layer blockchain network; as shown... Figure 8 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 1dThe 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 transfer between the aforementioned first and second business branch chains takes place 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.

[0083] 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 9 .

[0084] like Figure 9 As 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 901, consensus node 902, consensus node 903, 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.

[0085] As mentioned above Figure 1dAs 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 9 The core consensus network shown may include a consensus cluster 904, which may include consensus nodes 901 and 902 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 stated here. 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 core consensus clusters and branch chain consensus clusters. For details regarding core consensus clusters and branch chain consensus clusters, please refer to the foregoing. Figure 1d The specific implementation details shown are not elaborated here.

[0086] The following is combined with Figure 10a This section introduces a two-layer network architecture; such as... Figure 10a As 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 business main chain or 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 core consensus node that maintains the business main chain, and the core consensus node will process the business data according to the chain identifier of each business branch chain derived from the business main chain (such as forwarding it to the corresponding business branch chain).

[0087] based on Figure 10a The description of the two-layer network architecture shown below, combined with... Figure 10a and Figure 10b The specific implementation of the cross-blockchain processing method proposed in this application embodiment under a two-layer network architecture is briefly described, wherein the cross-blockchain processing method may include steps s11-s21: S11: The business nodes in the witness sub-network send transaction processing requests to the routing agent nodes in the routing agent network. These requests may include derivation requests and transaction transfer requests. A derivation request can be used to request the deriving of a new business branch chain from the existing business branch chain. In this implementation, the derivation request may carry the chain identifier of the main business chain and the business configuration information of the new business branch chain to be created. A transaction transfer request can be used to request the transfer of a target transaction from the first business branch chain to the second business branch chain. In this implementation, the transaction transfer request carries the transaction identifier of the target transaction (such as a transaction ID, used to uniquely identify the target transaction), the chain identifier of the first business branch chain, and the chain identifier of the second business branch chain. For ease of explanation, the following description will use a transaction transfer request as an example.

[0088] s12: The routing proxy network forwards transaction transfer requests to the consensus subnetwork. In one implementation, if a business node in the witness subnetwork has specified a consensus node to receive the transaction transfer request when sending it to the routing proxy network, the routing proxy node can directly send the transaction transfer request to the specified consensus node in the consensus subnetwork based on the specified recipient. One way to specify the consensus node to receive the transaction transfer request is to carry the node identifier of the consensus node in the transaction transfer request. In another implementation, the routing proxy node can also directly send the transaction transfer request to the consensus node in the consensus subnetwork that maintains the chain corresponding to the chain identifier based on the chain identifier carried in the transaction transfer request. For example, the chain identifier is the identifier of business branch chain 1031, and business branch chain 1031 is maintained by the chain consensus cluster 1001 (e.g., ...). Figure 10a If the routing proxy network maintains the transaction flow request (as shown), it can directly send the transaction flow request to the business consensus node in the sub-chain consensus cluster 1001, such as business consensus node 1 (referred to as the "source consensus node" in this application). In other implementations, the routing proxy network can send the transaction flow request to the core consensus node in the consensus sub-network that maintains the main business chain. The core consensus node then responds to the transaction flow request and calls the corresponding business branch to execute the cross-chain flow operation of the target transaction.

[0089] It should be noted that this application embodiment does not limit the specific sending method used by the routing proxy network to forward transaction flow requests, which is explained here. Furthermore, based on security considerations for the consensus subnetwork, this application embodiment introduces a routing proxy network to isolate the witness subnetwork and the consensus subnetwork. However, in practical applications, the witness subnetwork and the consensus subnetwork can communicate directly, meaning that communication between the witness subnetwork and the consensus subnetwork does not need to be implemented by the routing proxy network.

[0090] s13: The source consensus node receives a transaction transfer request forwarded by the routing proxy network and, in response to the transaction transfer request, generates a pre-transfer block for the target transaction in the first business branch chain. In other words, the aforementioned transaction transfer event can include, in addition to detecting the lifecycle of the target transaction in the first business branch chain as being in an operable state and meeting the transaction transfer conditions, also including: the source consensus node determining the existence of a transaction transfer event when it receives a transaction transfer request for the target transaction forwarded by the routing proxy network. It should be noted that the specific implementation of the source consensus node generating a pre-transfer block for the target transaction in the first business branch chain in response to the transaction transfer event can be found in [link to relevant documentation]. Figure 2 The specific implementation details of step S201 in the illustrated embodiment will not be repeated here.

[0091] s14: The source consensus node sends a pre-transfer request to the target consensus node where the second business branch chain is located based on the pre-transfer block.

[0092] s15: The target consensus node responds to the pre-transfer request and generates the pre-received result of the target transaction in the second business branch chain.

[0093] s16: The target consensus node sends a feedback message generated based on the pre-received results back to the source consensus node.

[0094] s17: The source consensus node responds to the feedback message and, after successfully verifying the pre-received result, generates the corresponding transferred block of the target transaction in the first business branch chain.

[0095] s18: The source consensus node sends a notification that the data has been transferred to the target consensus node.

[0096] s19: The target consensus node responds to the circulation notification by generating an operable block for the target transaction in the second business branch chain.

[0097] It should be noted that the specific implementation process of steps s14-s19 can be found in the aforementioned... Figure 2 and / or Figure 5 The specific implementation process of the illustrated embodiment will not be described in detail here.

[0098] s20: The target consensus node sends a transfer notification message to the routing proxy node. This transfer notification message is used to notify the target transaction whether the transfer was successful or failed.

[0099] s21: The routing proxy node forwards the flow notification message to the service node. It is worth noting that the target consensus node stores the node identifier and address of the service node (or SPV node). Therefore, the target consensus node can also directly send the flow notification message to the service node based on the node identifier and address of the service node. This application does not limit the specific implementation method of the target consensus node returning the flow notification message; it is only described here.

[0100] In summary, on the one hand, the two-layer network architecture proposed in this application isolates the witness sub-network and the consensus sub-network through a routing proxy network, thereby improving the security of business data stored in the consensus sub-network to a certain extent. On the other hand, this application embodiment can transfer the target transaction and the operation permissions that can operate on the target transaction from the first business branch chain to (or transfer to) the second business branch chain, realizing the cross-chain transfer of the target transaction between different business branch chains; and by setting the corresponding state of the target transaction (such as pre-transfer state, pre-receive state, and transferred state, etc.) in each step of the transfer, the consistency of the state changes of the target transaction during the transfer process is maintained, and the uniqueness and security of the operation performed on the target transaction during the transfer process are ensured.

[0101] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the methods of the embodiments of this application, the apparatus of the embodiments of this application is provided below.

[0102] Figure 11 This illustration shows a schematic diagram of the structure of a cross-blockchain transaction processing device according to an exemplary embodiment of this application. The cross-blockchain transaction processing device may be a computer program (including program code) running on the source consensus node; the cross-blockchain transaction processing device can be used to execute... Figure 2 and Figure 10b The method embodiments shown include some or all of the steps, and the cross-blockchain processing device for this transaction includes the following units: Processing unit 1101 is configured to generate a pre-transfer block for the target transaction in the first business branch chain in response to a detected transaction transfer event that transfers the target transaction from the first business branch chain to the second business branch chain. The communication unit 1102 is used to send a pre-transfer request to the target consensus node where the second business branch chain is located based on the pre-transfer block. The pre-transfer request is used to request the target consensus node to generate a pre-received result of the target transaction in the second business branch chain. The processing unit 1101 is also used to receive feedback messages returned by the target consensus node based on the pre-received results, and after successfully verifying the feedback messages, generate the transferred blocks corresponding to the target transaction in the first business branch chain; The communication unit 1102 is also used to send a circulation notification to the target consensus node based on the circulation block. The circulation notification is used to notify the target consensus node to generate an operable block of the target transaction in the second business branch chain.

[0103] In one implementation, the processing unit 1101, when receiving the feedback message returned by the target consensus node based on the pre-received result, is specifically used for: Within the first timeout period after sending the pre-transfer request, check whether a feedback message has been received from the target consensus node based on the pre-received result; If a feedback message is received within the first timeout waiting period, the status of the target transaction on the second business branch chain is verified based on the feedback message to obtain the pre-receive verification result.

[0104] In one implementation, the pre-received result includes: the state information of the target transaction in the second business branch chain, and the pre-received signature information corresponding to the target transaction. The pre-received signature information is generated by the target consensus node signing the target transaction using its private key. The processing unit 1101 is used to verify the state of the target transaction on the second business branch chain based on the feedback message. When obtaining the pre-received verification result, it is specifically used for: Obtain the public key of the target consensus node; The public key of the target consensus node is used to verify the pre-received signature information to obtain the verification result. A pre-receive verification result is generated based on the status information and the signature verification result; wherein, when the status information indicates that the target transaction is in the pre-receive state in the second business branch chain, and the signature verification result indicates that the signature verification of the pre-received signature information is successful, the pre-receive verification result indicates that the pre-received result verification is successful.

[0105] In one implementation, the processing unit 1101 is further configured to: In response to the detected state rollback condition for the target transaction, a first state rollback process is performed on the target transaction in the first business branch chain. The first state rollback process includes: setting the state of the target transaction in the first business branch chain to an operable state. The state rollback condition includes: not receiving the pre-received result within the first timeout waiting period, or receiving the pre-received result within the first timeout waiting period and failing to verify the pre-received result. Based on the target transaction that is in an operable state after state rollback processing, an operable block is generated and stored in the first business branch chain.

[0106] In one implementation, the processing unit 1101, when generating a pre-transfer block for the target transaction in the first business branch chain, is specifically used for: In the first business branch chain, the target transaction is pre-transfer processed. The pre-transfer process includes setting the state of the target transaction in the first business branch chain to the pre-transfer state. Sign the target transaction that is in the pre-transfer state after pre-transfer processing to generate pre-transfer signature information; The target transaction and pre-transfer signature information in the pre-transfer state are packaged and processed to generate a pre-transfer block.

[0107] In one implementation, the pre-transfer state of the target transaction in the first business branch chain is locked. Once locked, the target transaction cannot be transferred to the third business branch chain, which is different from the second business branch chain.

[0108] In one implementation, the methods for determining whether a transaction transition event has been detected include: When a transaction transfer request for a target transaction is received forwarded by the routing proxy network, a transaction transfer event is determined to have been detected. The routing proxy network is a blockchain network, which includes a witness subnetwork and a consensus subnetwork. The witness subnetwork includes one or more business nodes, and the consensus subnetwork includes one or more consensus nodes. The routing proxy node is used to isolate the witness subnetwork and the consensus subnetwork. Alternatively, the lifecycle of a target transaction in an operable state in the first business branch chain is detected, and a transaction transition event is determined to have been detected when the transaction transition conditions are met.

[0109] According to one embodiment of this application, Figure 11 The various units in the cross-blockchain processing device for transactions shown can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the cross-blockchain processing device for transactions may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units. According to another embodiment of this application, the device can be used to execute functions such as those described above by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access storage medium (RAM), and read-only storage medium (ROM). Figure 2 and Figure 10b The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 11The diagram illustrates a cross-blockchain transaction processing apparatus and a cross-blockchain transaction processing method for implementing embodiments of this application. A computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the same medium, and executed therein.

[0110] In this embodiment, in response to a detected transaction transfer event that moves a target transaction from the first business branch chain to the second business branch chain, the processing unit 1101 can transfer the target transaction from the first business branch chain to the second business branch chain, realizing cross-chain transfer of the target transaction between different business branch chains. Furthermore, during each step of the target transaction transfer process, a corresponding transfer state (such as pre-transfer state, pre-receive state, and transferred state) is set for the target transaction on the business branch chain. For example, during cross-chain transfer, the target transaction is first set from the operable state to the pre-receive state in the first business branch chain to indicate that the target transaction is ready to transfer to the second business branch chain, and then the state of the target transaction is set to the pre-receive state on the second business branch chain to indicate that the second business branch chain is ready to receive the target transaction, etc. This ensures the consistency of the target transaction's state changes during the transfer process and guarantees the uniqueness and security of the target transaction being operated on during the transfer process.

[0111] Figure 12 This illustration shows a schematic diagram of the structure of a cross-blockchain transaction processing device according to an exemplary embodiment of this application. The cross-blockchain transaction processing device can be a computer program (including program code) running on a target consensus node; the cross-blockchain transaction processing device can be used to execute... Figure 5 and Figure 10b The method embodiments shown include some or all of the steps, and the cross-blockchain processing device for this transaction includes the following units: The receiving unit 1201 is used to receive the pre-transfer request sent by the source consensus node. The pre-transfer request is used to request the generation of the pre-received result of the target transaction in the second business branch chain. The processing unit 1202 is configured to generate a pre-received result for the target transaction if the target transaction is successfully verified in response to the pre-transfer request. Processing unit 1202 is also used to return a feedback message generated based on the pre-received result to the source consensus node, so that the source consensus node generates the transferred block corresponding to the target transaction in the first business branch chain contained in the source consensus node based on the feedback message; The processing unit 1202 is also configured to generate an operable block of the target transaction in the second business branch chain in response to the circulation notification returned by the source consensus node. The circulation notification is returned by the source consensus node based on the circulation block, and the circulation notification is used to notify the generation of an operable block of the target transaction in the second business branch chain.

[0112] In one implementation, the processing unit 1202 is further configured to: Within the second timeout period after sending the feedback message, check whether a notification of completed transfer has been received from the source consensus node; If no feedback notification is received from the source consensus node within the second timeout waiting period, then obtain the access period for accessing the source consensus node; At each access cycle, an access request is sent to the source consensus node. The access request is used to request the source consensus node to return a notification that the data has been transferred, until the source consensus node returns the notification that the data has been transferred.

[0113] In one implementation, the processing unit 1202, when generating a pre-received result for the target transaction in the second business branch chain, is specifically used for: Set the target transaction's status to the pre-receive state on the second business branch chain; Sign the target transaction in the pre-received state to obtain the pre-received signature information; The target transaction and pre-received signature information in the pre-received state are packaged and processed to generate the pre-received result.

[0114] In one implementation, when the target transaction is in the pre-receive state on the second business branch chain, the transaction information of the target transaction cannot be used. Use includes: access, processing, and transfer.

[0115] According to one embodiment of this application, Figure 12 The various units in the cross-blockchain processing device for transactions shown can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the cross-blockchain processing device for transactions may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units. According to another embodiment of this application, the device can be used to execute functions such as those described above by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access storage medium (RAM), and read-only storage medium (ROM). Figure 5 and Figure 10b The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 12The diagram illustrates a cross-blockchain transaction processing apparatus and a cross-blockchain transaction processing method for implementing embodiments of this application. A computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the same medium, and executed therein.

[0116] In this embodiment, the processing unit 1202, in response to a transaction transfer event that moves a target transaction from a first business branch chain to a second business branch chain, can transfer the target transaction and the operational permissions that can operate on the target transaction between different business branch chains, realizing cross-chain transfer of the target transaction. Furthermore, during the transfer of the target transaction, the state of the target transaction on the business branch chain is locked after each transfer step. For example, when the state of the target transaction is set to a pre-transfer state in the first business branch chain, the pre-transfer state of the target transaction on the first business branch chain is locked, preventing the target transaction in the pre-transfer state from transferring to other business branch chains (such as business branch chains different from the second business branch chain). This ensures the consistency of the target transaction's state changes and eliminates reliance on a third-party service center to control the cross-chain process of the target transaction, reducing the cost of cross-chain transaction transfer. In addition, this embodiment also introduces a timeout rollback mechanism to improve the fault tolerance and robustness of the cross-chain transaction transfer process, enabling the cross-blockchain processing solution provided by this embodiment to be applied to transaction transfers in more complex blockchain networks, improving the scalability of the corresponding application scenarios.

[0117] Figure 13 A schematic diagram of the structure of a smart device provided in an exemplary embodiment of this application is shown. Please refer to... Figure 13 The intelligent device includes a processor 1301, a communication interface 1302, and a computer-readable storage medium 1303. The processor 1301, communication interface 1302, and computer-readable storage medium 1303 can be connected via a bus or other means. The communication interface 1302 is used to receive and send data. The computer-readable storage medium 1303 can be stored in the terminal's memory and is used to store computer programs, including program instructions. The processor 1301 is used to execute the program instructions stored in the computer-readable storage medium 1303. The processor 1301 (or CPU (Central Processing Unit)) is the computing and control core of the intelligent device, suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to achieve corresponding method flows or corresponding functions.

[0118] This application embodiment also provides a computer-readable storage medium (Memory), which is a memory device in a smart device for storing programs and data. It is understood that the computer-readable storage medium here can include both the built-in storage medium in the smart device and extended storage media supported by the smart device. The computer-readable storage medium provides storage space that stores the processing system of the smart device. Furthermore, the storage space also stores one or more instructions suitable for loading and execution by the processor 1301, which can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer-readable storage medium located remotely from the aforementioned processor.

[0119] In one embodiment, the computer-readable storage medium stores one or more instructions; the processor 1301 loads and executes one or more instructions stored in the computer-readable storage medium to implement the corresponding steps in the above-mentioned cross-blockchain transaction processing method embodiment; specifically, the one or more instructions in the computer-readable storage medium are loaded and executed by the processor 1301 in the following steps: In response to a detected transaction transfer event that moves the target transaction from the first business branch chain to the second business branch chain, a pre-transfer block is generated for the target transaction in the first business branch chain; Based on the pre-transfer block, a pre-transfer request is sent to the target consensus node where the second business branch chain is located. The pre-transfer request is used to request the target consensus node to generate the pre-receive result of the target transaction in the second business branch chain. Receive feedback messages returned by the target consensus node based on the pre-received results, and after successfully verifying the feedback messages, generate the corresponding circulated block of the target transaction in the first business branch chain; Based on the already circulated blocks, a circulation notification is sent to the target consensus node. The circulation notification is used to notify the target consensus node to generate an operable block for the target transaction in the second business branch chain.

[0120] In one implementation, one or more instructions in the computer-readable storage medium are loaded by the processor 1301 and, when executing the feedback message returned by the target consensus node based on the pre-received result, specifically perform the following steps: Within the first timeout period after sending the pre-transfer request, check whether a feedback message has been received from the target consensus node based on the pre-received result; If a feedback message is received within the first timeout waiting period, the status of the target transaction on the second business branch chain is verified based on the feedback message to obtain the pre-receive verification result.

[0121] In one implementation, the pre-received result includes: the state information of the target transaction in the second business branch chain, and the pre-received signature information corresponding to the target transaction. The pre-received signature information is generated by the target consensus node signing the target transaction using its private key. One or more instructions in the computer-readable storage medium are loaded by the processor 1301 and executed. When verifying the state of the target transaction on the second business branch chain according to the feedback message and obtaining the pre-received verification result, the following steps are specifically performed: Obtain the public key of the target consensus node; The public key of the target consensus node is used to verify the pre-received signature information to obtain the verification result. A pre-receive verification result is generated based on the status information and the signature verification result; wherein, when the status information indicates that the target transaction is in the pre-receive state in the second business branch chain, and the signature verification result indicates that the signature verification of the pre-received signature information is successful, the pre-receive verification result indicates that the pre-received result verification is successful.

[0122] In one implementation, one or more instructions in a computer-readable storage medium are loaded by processor 1301 and the following steps are also performed: In response to the detected state rollback condition for the target transaction, a first state rollback process is performed on the target transaction in the first business branch chain. The first state rollback process includes: setting the state of the target transaction in the first business branch chain to an operable state. The state rollback condition includes: not receiving the pre-received result within the first timeout waiting period, or receiving the pre-received result within the first timeout waiting period and failing to verify the pre-received result. Based on the target transaction that is in an operable state after state rollback processing, an operable block is generated and stored in the first business branch chain.

[0123] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1301 and executed in the first business branch chain to generate a pre-transfer block for the target transaction, the following steps are specifically performed: In the first business branch chain, the target transaction is pre-transfer processed. The pre-transfer process includes setting the state of the target transaction in the first business branch chain to the pre-transfer state. Sign the target transaction that is in the pre-transfer state after pre-transfer processing to generate pre-transfer signature information; The target transaction and pre-transfer signature information in the pre-transfer state are packaged and processed to generate a pre-transfer block.

[0124] In one implementation, the pre-transfer state of the target transaction in the first business branch chain is locked. Once locked, the target transaction cannot be transferred to the third business branch chain, which is different from the second business branch chain.

[0125] In one implementation, the methods for determining whether a transaction transition event has been detected include: When a transaction transfer request for a target transaction is received forwarded by the routing proxy network, a transaction transfer event is determined to have been detected. The routing proxy network is a blockchain network, which includes a witness subnetwork and a consensus subnetwork. The witness subnetwork includes one or more business nodes, and the consensus subnetwork includes one or more consensus nodes. The routing proxy node is used to isolate the witness subnetwork and the consensus subnetwork. Alternatively, the lifecycle of a target transaction in an operable state in the first business branch chain is detected, and a transaction transition event is determined to have been detected when the transaction transition conditions are met.

[0126] In another embodiment, the computer-readable storage medium stores one or more instructions; the processor 1301 loads and executes one or more instructions stored in the computer-readable storage medium to implement the corresponding steps in the above-described cross-blockchain transaction processing method embodiment; specifically, the one or more instructions in the computer-readable storage medium are loaded by the processor 1301 and executed as follows: Receive the pre-transfer request sent by the source consensus node. The pre-transfer request is used to request the generation of the pre-received result of the target transaction in the second business branch chain. If the target transaction is successfully verified in response to the pre-transfer request, a pre-received result is generated for the target transaction. Return a feedback message generated based on the pre-received result to the source consensus node, so that the source consensus node can generate the transferred block corresponding to the target transaction in the first business branch chain contained in the source consensus node according to the feedback message; In response to the circulation notification returned by the source consensus node, an operable block for the target transaction is generated in the second business branch chain. The circulation notification is returned by the source consensus node based on the circulation block and is used to notify the generation of an operable block for the target transaction in the second business branch chain.

[0127] In one implementation, one or more instructions in a computer-readable storage medium are loaded by processor 1301 and further executed as follows: Within the second timeout period after sending the feedback message, check whether a notification of completed transfer has been received from the source consensus node; If no feedback notification is received from the source consensus node within the second timeout waiting period, then obtain the access period for accessing the source consensus node; At each access cycle, an access request is sent to the source consensus node. The access request is used to request the source consensus node to return a notification that the data has been transferred, until the source consensus node returns the notification that the data has been transferred.

[0128] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1301 and executed in the second business branch chain to generate a pre-received result for the target transaction, the following steps are specifically performed: Set the target transaction's status to the pre-receive state on the second business branch chain; Sign the target transaction in the pre-received state to obtain the pre-received signature information; The target transaction and pre-received signature information in the pre-received state are packaged and processed to generate the pre-received result.

[0129] In one implementation, when the target transaction is in the pre-receive state on the second business branch chain, the transaction information of the target transaction cannot be used. Use includes: access, processing, and transfer.

[0130] In this embodiment, in response to a detected transaction transfer event that moves a target transaction from the first business branch chain to the second business branch chain, the source node can transfer the target transaction from the first business branch chain to the second business branch chain, thus enabling cross-chain transfer of the target transaction between different business branch chains. Furthermore, during each step of the target transaction transfer process, a corresponding transfer state (such as pre-transfer state, pre-receive state, and transferred state) is set for the target transaction on the business branch chain. For example, during cross-chain transfer, the target transaction is first set from the operable state to the pre-receive state in the first business branch chain to indicate that the target transaction is ready to transfer to the second business branch chain. Then, the state of the target transaction is set to the pre-receive state on the second business branch chain to indicate that the second business branch chain is ready to receive the target transaction, and so on. This ensures the consistency of the target transaction's state changes during the transfer process and guarantees the uniqueness and security of the target transaction during the transfer process.

[0131] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. The processor of a smart device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the smart device to perform the aforementioned cross-blockchain processing method for transactions.

[0132] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0133] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data processing device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0134] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this invention should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for cross-blockchain transaction processing, characterized in that, include: In response to a detected transaction transfer event that moves a target transaction from a first business branch chain to a second business branch chain, the target transaction is modified from an operable state to a pre-transfer state, and a pre-transfer block is generated for the target transaction in the first business branch chain. Based on the pre-transfer block, a pre-transfer request is sent to the target consensus node where the second business branch chain is located. The pre-transfer request is used to request the target consensus node to generate a pre-receive result of the target transaction in the second business branch chain. The target consensus node where the second business branch chain is located responds to the pre-transfer request by performing cross-chain verification on the pre-transfer block, and after successful verification, sets the state of the target transaction to the pre-receive state and generates a pre-receive block on the second business branch chain; The cross-chain verification includes: verifying whether the target transaction is in a pre-transfer state in the first business branch chain, and verifying whether the transfer of the target transaction meets the transfer requirements of the target consensus node where the second business branch chain is located; Receive feedback messages returned by the target consensus node based on the pre-received results, wherein the pre-received results include: the status information of the target transaction in the second business branch chain; When the target transaction on the second business branch chain is verified to be in the pre-received state according to the feedback message, the target transaction is adjusted from the pre-transfer state to the transferred state, and a transferred block corresponding to the target transaction is generated in the first business branch chain. According to the already circulated block, a circulation notification is sent to the target consensus node. The circulation notification is used to notify the target consensus node to generate an operable block of the target transaction in the second business branch chain. The target consensus node where the second business branch chain is located performs cross-chain verification on the target transaction in the first business branch chain according to the circulation notification. After successful verification, the target transaction is adjusted from the pre-received state to the operable state and an operable block is generated on the second business branch chain. The cross-chain verification includes: verifying whether the target transaction is in the already circulated state in the first business branch chain.

2. The method as described in claim 1, characterized in that, The step of receiving the feedback message returned by the target consensus node based on the pre-received result includes: Within the first timeout period after sending the pre-transfer request, it is detected whether a feedback message returned by the target consensus node based on the pre-received result has been received; If the feedback message is received within the first timeout waiting period, the status of the target transaction on the second business branch chain is verified according to the feedback message to obtain the pre-receive verification result.

3. The method as described in claim 2, characterized in that, The pre-received result also includes pre-received signature information corresponding to the target transaction, which is generated by the target consensus node signing the target transaction using the node private key of the target consensus node; The step of verifying the status of the target transaction on the second business branch chain according to the feedback message to obtain the pre-receive verification result includes: Obtain the public key of the target consensus node; The public key of the target consensus node is used to verify the pre-received signature information to obtain the verification result. A pre-receive verification result is generated based on the status information and the signature verification result; wherein, when the status information indicates that the target transaction is in a pre-receive state in the second business branch chain, and the signature verification result indicates that the pre-receive signature information has been successfully verified, the pre-receive verification result indicates that the pre-receive result has been successfully verified.

4. The method as described in claim 1, characterized in that, After sending the pre-transfer request to the target consensus node where the second business branch chain is located based on the pre-transfer block, the process further includes: In response to the detected state rollback condition for the target transaction, a state rollback process is performed on the target transaction in the first business branch chain. The state rollback process includes: setting the state of the target transaction in the first business branch chain to an operable state. The state rollback condition includes: not receiving the feedback message within a first timeout waiting period, or receiving the feedback message within the first timeout waiting period and failing to verify the feedback message. Based on the target transaction that is in an operable state after state rollback processing, an operable block is generated and the operable block is stored in the first business branch chain.

5. The method as described in claim 1, characterized in that, The step of generating a pre-transfer block for the target transaction in the first business branch chain includes: In the first business branch chain, the target transaction is pre-transfer processed, and the pre-transfer process includes: setting the state of the target transaction in the first business branch chain to a pre-transfer state; Sign the target transaction that is in the pre-transfer state after pre-transfer processing to generate pre-transfer signature information; The target transaction in the pre-transfer state and the pre-transfer signature information are packaged to generate a pre-transfer block.

6. The method as described in claim 5, characterized in that, The target transaction is locked in the pre-transfer state in the first business branch chain. Once locked, the target transaction cannot be transferred to the third business branch chain, which is different from the second business branch chain.

7. The method as described in claim 1, characterized in that, Determining that the transaction flow event has been detected includes: When a transaction transfer request for a target transaction is received forwarded by the routing proxy network, a transaction transfer event is determined to have been detected; wherein, the routing proxy network belongs to a blockchain network, the blockchain network includes a witness sub-network and a consensus sub-network, the witness sub-network includes one or more business nodes, the consensus sub-network includes one or more consensus nodes, and the routing proxy node is used to isolate the witness sub-network and the consensus sub-network. Alternatively, the lifecycle of a target transaction in an operable state in the first business branch chain is detected, and a transaction transition event is determined to have been detected when the transaction transition conditions are met.

8. A method for cross-blockchain transaction processing, characterized in that, include: Receive a pre-transfer request sent by the source consensus node, the pre-transfer request being used to request the generation of a pre-received result of the target transaction in the second business branch chain; The pre-transfer request is generated by the source consensus node for the target transaction based on the pre-transfer block; The pre-transfer block is generated by the source consensus node in the first business branch chain after modifying the target transaction from the operable state to the pre-transfer state in the first business branch chain; If the target transaction is successfully verified in response to the pre-transfer request, a pre-receive result is generated for the target transaction. The successful verification of the target transaction refers to: cross-chain verification of the pre-transfer block in response to the pre-transfer request, the cross-chain verification including: verifying whether the target transaction is in a pre-transfer state in the first business branch chain, and verifying whether the transfer of the target transaction meets the transfer requirements of the target consensus node where the second business branch chain is located; the generation of the pre-receive result includes: setting the state of the target transaction to a pre-receive state and generating a pre-receive block on the second business branch chain; The source consensus node returns a feedback message generated based on the pre-received result, so that when the source consensus node verifies that the target transaction on the second business branch chain is in the pre-received state according to the feedback message, it adjusts the target transaction from the pre-transfer state to the transferred state, and generates the transferred block corresponding to the target transaction in the first business branch chain included in the source consensus node. In response to the completed transaction notification returned by the source consensus node, cross-chain verification is performed on the target transaction in the first business branch chain. After successful verification, the target transaction is adjusted from the pre-received state to the operable state on the second business branch chain, and an operable block of the target transaction is generated in the second business branch chain. The completed transaction notification is returned by the source consensus node based on the completed transaction block, and the completed transaction notification is used to notify the generation of an operable block of the target transaction in the second business branch chain. The cross-chain verification includes verifying whether the target transaction is in the completed transaction state in the first business branch chain.

9. The method as described in claim 8, characterized in that, After returning the feedback message generated based on the pre-received result to the source consensus node, the method further includes: Within the second timeout period after sending the feedback message, check whether a notification of completed transfer has been received from the source consensus node; If the notification of successful transfer is not received within the second timeout waiting period, then the access period for accessing the source consensus node is obtained; At each access cycle, an access request is sent to the source consensus node. The access request is used to request the source consensus node to return a notification that the data has been transferred, until the source consensus node returns the notification that the data has been transferred.

10. The method as described in claim 8, characterized in that, The step of generating a pre-received result for the target transaction includes: On the second business branch chain, the state of the target transaction is set to the pre-receive state; Sign the target transaction in the pre-received state to obtain pre-received signature information; The target transaction in the pre-received state and the pre-received signature information are packaged together to generate a pre-received result.

11. The method as described in claim 10, characterized in that, When the target transaction is in the pre-receive state on the second business branch chain, the transaction information of the target transaction cannot be used. The use includes: access, processing, and transfer.

12. A cross-blockchain transaction processing device, characterized in that, include: The processing unit is configured to, in response to a detected transaction flow event that transfers a target transaction from a first business branch chain to a second business branch chain, modify the target transaction from an operable state to a pre-flow state, and generate a pre-flow block for the target transaction in the first business branch chain; A communication unit is used to send a pre-transfer request to the target consensus node where the second business branch chain is located based on the pre-transfer block. The pre-transfer request is used to request the target consensus node to generate a pre-receive result of the target transaction in the second business branch chain. The target consensus node where the second business branch chain is located responds to the pre-transfer request by performing cross-chain verification on the pre-transfer block, and after successful verification, sets the state of the target transaction to the pre-receive state and generates a pre-receive block on the second business branch chain; The cross-chain verification includes: verifying whether the target transaction is in a pre-transfer state in the first business branch chain, and verifying whether the transfer of the target transaction meets the transfer requirements of the target consensus node where the second business branch chain is located; The processing unit is further configured to receive a feedback message returned by the target consensus node based on the pre-received result, wherein the pre-received result includes: the status information of the target transaction in the second business branch chain; When the target transaction on the second business branch chain is verified to be in the pre-received state according to the feedback message, the target transaction is adjusted from the pre-transfer state to the transferred state, and a transferred block corresponding to the target transaction is generated in the first business branch chain. The communication unit is further configured to send a circulation notification to the target consensus node based on the circulation block, the circulation notification being used to notify the target consensus node to generate an operable block of the target transaction in the second business branch chain; the target consensus node where the second business branch chain is located performs cross-chain verification on the target transaction in the first business branch chain based on the circulation notification, and after successful verification, adjusts the target transaction from the pre-received state to the operable state and generates an operable block on the second business branch chain; the cross-chain verification includes: verifying whether the target transaction is in the circulation state in the first business branch chain.

13. A cross-blockchain transaction processing device, characterized in that, include: The receiving unit is used to receive a pre-transfer request sent by the source consensus node in the consensus sub-network. The pre-transfer request carries the transaction information of the target transaction and is used to request the generation of a pre-received result of the target transaction in the second business branch chain. The pre-transfer request is generated by the source consensus node for the target transaction based on the pre-transfer block; The pre-transfer block is generated by the source consensus node in the first business branch chain after modifying the target transaction from the operable state to the pre-transfer state in the first business branch chain; The processing unit is configured to generate a pre-receive result for the target transaction in the second business branch chain if the target transaction is successfully verified in response to the pre-transfer request. The successful verification of the target transaction refers to: cross-chain verification of the pre-transfer block in response to the pre-transfer request, the cross-chain verification including: verifying whether the target transaction is in a pre-transfer state in the first business branch chain, and verifying whether the transfer of the target transaction meets the transfer requirements of the target consensus node where the second business branch chain is located; the generation of the pre-receive result includes: setting the state of the target transaction to a pre-receive state and generating a pre-receive block on the second business branch chain; The processing unit is further configured to return a feedback message generated based on the pre-received result to the source consensus node, so that when the source consensus node verifies that the target transaction on the second business branch chain is in the pre-received state according to the feedback message, it adjusts the target transaction from the pre-transfer state to the transferred state, and generates the transferred block corresponding to the target transaction in the first business branch chain included in the source consensus node; The processing unit is further configured to, in response to the completed transaction notification returned by the source consensus node, perform cross-chain verification on the target transaction in the first business branch chain, and, upon successful verification, adjust the target transaction from the pre-received state to the operable state on the second business branch chain, and generate an operable block for the target transaction in the second business branch chain; the completed transaction notification is returned by the source consensus node based on the completed transaction block, and the completed transaction notification is used to notify the generation of an operable block for the target transaction in the second business branch chain; the cross-chain verification includes: verifying whether the target transaction is in the completed transaction state in the first business branch chain.

14. A smart device, characterized in that, include: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements the cross-blockchain transaction processing method as described in any one of claims 1-7, or implements the cross-blockchain transaction processing method as described in any one of claims 8-11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and execute the cross-blockchain transaction processing method as described in any one of claims 1-7, or to implement the cross-blockchain transaction processing method as described in any one of claims 8-11.

16. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the cross-blockchain transaction processing method as described in any one of claims 1-7, or implement the cross-blockchain transaction processing method as described in any one of claims 8-11.

Images