Cross-block chain transaction processing method and device, electronic equipment and storage medium

Abstract

The invention provides a cross-block chain transaction processing method and device, electronic equipment and a storage medium. The cross-block chain transaction processing method comprises the following steps: acquiring a transaction to be subjected to cross-chain processing; obtaining a block valid proof queue, and storing block valid proof of the cochain blocks according to a cochain sequence of the cochain blocks on the first block chain by the block valid proof queue, when the uplink block is recorded to the first block chain, the cross-chain relay node carries out block verification on the uplink block to generate a block valid proof of the uplink block, and the block valid proof is put into a block valid proof queue; obtaining a target block valid proof corresponding to the transaction to be subjected to cross-chain processing from the block valid proof queue, and generating a transaction valid proof based on the target block valid proof; and sending the transaction validity proof to the second block chain network, so that the second block chain network records the transaction to be subjected to cross-chain processing to the second block chain based on the transaction validity proof. According to the embodiment of the invention, the cross-block chain transaction processing efficiency can be improved.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain, and in particular to a cross-blockchain transaction processing method, device, electronic device and storage medium. Background Art

[0002] In the field of blockchain, different blockchain networks sometimes need to communicate data, for example, the parent chain and the child chain in the field of blockchain. The parent chain and the child chain can be two independent blockchain networks, but the child chain is often created based on the parent chain, and some transactions in the child chain also need to be recorded on the parent chain. In order to ensure the security of transaction processing in the blockchain, different blockchain networks cannot communicate data directly. In order to record transactions in one blockchain network in another blockchain network, the transaction needs to be verified to ensure that the transaction is valid and secure. In the related art, the process of verifying transactions requires the use of a large amount of transaction-related data and the block data of the blockchain where the transaction is located, which leads to low transaction verification efficiency, thereby making the cross-blockchain data transmission efficiency low. Summary of the invention

[0003] The embodiments of the present disclosure provide a cross-blockchain transaction processing method, device, electronic device and storage medium, which can improve the efficiency of cross-blockchain transaction processing.

[0004] According to one aspect of the present disclosure, a cross-blockchain transaction processing method is provided, the method being applied to a cross-chain relay node between a first blockchain network and a second blockchain network, the first blockchain network maintaining a first blockchain, the second blockchain network maintaining a second blockchain, the method comprising:

[0005] Obtaining a transaction to be processed across the chain, wherein the transaction to be processed across the chain has been recorded in the first blockchain and needs to be recorded in the second blockchain;

[0006] Obtaining a block validity proof queue, wherein the block validity proof queue stores the block validity proof of the chained block according to the chaining order of the chained block on the first blockchain, wherein the block validity proof of the chained block is generated by the cross-chain relay node performing block verification on the chained block when the chained block is recorded in the first blockchain and is placed in the block validity proof queue;

[0007] Obtaining the target block validity certificate corresponding to the transaction to be processed across the chain from the block validity certificate queue, and generating a transaction validity certificate based on the target block validity certificate;

[0008] The transaction validity proof is sent to the second blockchain network so that the second blockchain network records the transaction to be processed across chains to the second blockchain based on the transaction validity proof.

[0009] According to one aspect of the present disclosure, a cross-blockchain transaction processing device is provided, wherein the cross-blockchain transaction processing device is located at a cross-chain relay node between a first blockchain network and a second blockchain network, and includes:

[0010] A first acquisition unit, configured to acquire a transaction to be processed across the chain, wherein the transaction to be processed across the chain has been recorded in the first blockchain and needs to be recorded in the second blockchain;

[0011] A second acquisition unit is used to acquire a block validity proof queue, wherein the block validity proof queue stores the block validity proof of the chained block according to the chaining order of the chained block on the first blockchain, wherein the block validity proof of the chained block is generated by the cross-chain relay node performing block verification on the chained block when the chained block is recorded in the first blockchain and is placed in the block validity proof queue;

[0012] A first generating unit is configured to obtain a target block validity certificate corresponding to the to-be-cross-chain-processed transaction from the block validity certificate queue, and generate a transaction validity certificate based on the target block validity certificate;

[0013] The first sending unit is used to send the transaction validity certificate to the second blockchain network, so that the second blockchain network records the transaction to be cross-chain processed to the second blockchain based on the transaction validity certificate.

[0014] Optionally, the block validity proof queue is pre-generated in the following manner:

[0015] Obtaining an additional block added to the first blockchain;

[0016] Verifying the added block using a block verification algorithm to generate a block validity certificate for the added block;

[0017] The block validity proof is recorded in the block validity proof queue according to the block height of the added block in the first blockchain.

[0018] Optionally, the verifying the added block by using a block verification algorithm to generate the block validity certificate of the added block includes:

[0019] Obtaining a first block header of the added block and a second block header of a block before the added block;

[0020] Performing block header verification based on the first block header and the second block header;

[0021] If the block header verification succeeds, and the previous block certificate corresponding to the previous block height of the added block is obtained from the block validity certificate queue, the block validity certificate of the added block is generated.

[0022] Optionally, the first block header includes a first block digest of the previous block, and the second block header includes a second block digest of the previous block;

[0023] The performing block header verification based on the first block header and the second block header includes:

[0024] If the first block digest is identical to the second block digest, it is determined that the block header verification is successful.

[0025] Optionally, if the block header verification succeeds, and a previous block certificate corresponding to a previous block height of the added block is obtained from the block validity certificate queue, generating the block validity certificate of the added block includes:

[0026] If the block header verification succeeds, and a previous block certificate corresponding to the previous block height of the added block is obtained from the block valid certificate queue, then a first signature of the first blockchain network recording the added block and a first key of the first blockchain network are obtained;

[0027] Decrypting the first signature using the first key to obtain a decryption result;

[0028] Calculating a digest of the added block, and comparing the digest with the decryption result;

[0029] If the digest is consistent with the decryption result, the block validity certificate of the added block is generated.

[0030] Optionally, the transaction to be processed across chains includes a block identifier of a target block;

[0031] The first generating unit is specifically used for:

[0032] In response to the target block validity proof, based on the block identifier, determining that the transaction to be cross-chain processed is located in the target block;

[0033] Based on the target block validity proof and the ownership relationship between the transaction to be processed across the chain and the target block, a transaction validity proof is generated.

[0034] Optionally, the first generating unit is specifically configured to:

[0035] Based on the block identifier, obtaining the Merkle tree root to be verified of the target block and the bypass digest value for verification of the transaction to be cross-chain processed in the target block;

[0036] Determine to recalculate the Merkle tree root based on the transaction to be processed across chains and the bypass digest value for verification;

[0037] If the Merkle tree root to be verified is the same as the recalculated Merkle tree root, it is determined that the transaction to be cross-chain processed is located in the target block.

[0038] Optionally, the first acquiring unit is specifically configured to:

[0039] Obtaining transactions uploaded to the first blockchain;

[0040] From the on-chain transactions that include the forwarding tag, obtain the transactions to be processed across the chain.

[0041] Optionally, the first acquiring unit is specifically configured to:

[0042] Storing the on-chain transaction including the forwarding tag in a transaction buffer pool;

[0043] After the transaction in the transaction buffer pool meets a predetermined condition, the transaction in the transaction buffer pool is taken out as the transaction to be processed across the chain.

[0044] Optionally, the on-chain transaction including the forwarding tag is generated in the first blockchain network in the following manner:

[0045] Obtaining a transaction to be uploaded to the chain, and determining a first transaction type of the transaction to be uploaded to the chain;

[0046] Obtaining a transaction processing contract corresponding to the first transaction type;

[0047] If the transaction to be on-chain meets the predetermined forwarding conditions in the transaction processing contract, the transaction processing contract adds the forwarding mark to the transaction to be on-chain, records the transaction to be on-chain in the first blockchain, and generates the on-chain transaction containing the forwarding mark.

[0048] According to one aspect of the present disclosure, a cross-blockchain transaction processing method is provided, the cross-blockchain transaction processing method is applied to a second blockchain network, the second blockchain network maintains a second blockchain, the method comprising:

[0049] Receive a transaction validity certificate from a cross-chain relay node, wherein the transaction validity certificate is generated by the cross-chain relay node for the transaction to be processed across the chain, based on the ownership relationship between the transaction to be processed across the chain and the target block, and the block validity certificate of the target block, wherein the transaction to be processed across the chain has been recorded in the first blockchain of the first blockchain network and needs to be recorded in the second blockchain, the block validity certificate is obtained from a block validity certificate queue, the block validity certificate queue stores the block validity certificate of the chained block according to the chaining order of the chained blocks on the first blockchain, and the block validity certificate is generated by the cross-chain relay node when the chained block is recorded in the first blockchain by performing block verification on the chained block and is placed in the block validity certificate queue;

[0050] Authenticating the identity of the cross-chain relay node based on the received transaction validity proof;

[0051] After the identity authentication is successful, the transaction to be processed across the chain is recorded in the second blockchain.

[0052] According to one aspect of the present disclosure, a cross-blockchain transaction processing device is provided, wherein the cross-blockchain transaction processing device is located in a second blockchain network and includes:

[0053] A receiving unit, configured to receive a transaction validity certificate from a cross-chain relay node, wherein the transaction validity certificate is generated by the cross-chain relay node for the transaction to be processed across the chain, based on the ownership relationship between the transaction to be processed across the chain and the target block, and the block validity certificate of the target block, wherein the transaction to be processed across the chain has been recorded in a first blockchain of a first blockchain network, and needs to be recorded in the second blockchain, the block validity certificate is obtained from a block validity certificate queue, the block validity certificate queue stores the block validity certificate of the chained block in the order of chaining the chained blocks on the first blockchain, and the block validity certificate is generated by the cross-chain relay node when the chained block is recorded in the first blockchain by performing block verification on the chained block and is placed in the block validity certificate queue;

[0054] A verification unit, configured to authenticate the identity of the cross-chain relay node based on the received transaction validity certificate;

[0055] A transaction recording unit is used to record the transaction to be processed across the chain into the second blockchain after the identity authentication is successful.

[0056] Optionally, the transaction validity proof is the transaction validity proof encrypted by the cross-chain relay node using a first private key, and the first private key is registered by the cross-chain relay node on a blockchain management contract stored on the second blockchain network and issued by the blockchain management contract;

[0057] The verification unit is specifically used for:

[0058] Obtaining a first public key of the cross-chain relay node from the blockchain management contract, wherein the first public key and the first private key are issued in pairs by the blockchain management contract;

[0059] The transaction validity certificate is decrypted using the first public key, thereby authenticating the identity of the cross-chain relay node.

[0060] Optionally, each of the first blockchain networks corresponds to one of the cross-chain relay nodes;

[0061] The second blockchain network registers the cross-chain relay node in the following manner:

[0062] Receiving a blockchain node registration request from the first blockchain network;

[0063] The blockchain management contract issues the first public key and the first private key to the cross-chain relay node corresponding to the first blockchain network;

[0064] Based on the blockchain node registration request, a blockchain verification contract corresponding to the first blockchain network is generated, wherein the blockchain verification contract is used to authenticate the identity of the cross-chain relay node using the first public key.

[0065] Optionally, the transaction recording unit is specifically used for:

[0066] After the identity verification is successful, obtaining a second transaction type of the transaction to be processed across the chain;

[0067] Retrieve a transaction summary contract corresponding to the second transaction type to generate a summary transaction based on the plurality of the to-be-processed cross-chain transactions of the second transaction type;

[0068] The aggregated transaction is recorded on the second blockchain.

[0069] Optionally, the cross-blockchain transaction processing device further includes:

[0070] A second generating unit, configured to generate a transaction processing feedback message based on the recorded result of the transaction to be cross-chain processed;

[0071] The second sending unit is used to send the transaction processing feedback message to the first blockchain network, so that the first blockchain updates the forwarding status of the transaction to be cross-chain processed, and the forwarding status indicates whether the transaction to be cross-chain processed is successfully recorded by the second blockchain.

[0072] According to one aspect of the present disclosure, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the cross-blockchain transaction processing method as described above is implemented.

[0073] According to one aspect of the present disclosure, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the cross-blockchain transaction processing method as described above is implemented.

[0074] According to one aspect of the present disclosure, a computer program product is provided, which includes a computer program, and the computer program is read and executed by a processor of a computer device, so that the computer device performs the cross-blockchain transaction processing method as described above.

[0075] The cross-blockchain transaction processing method in the disclosed embodiment is applied to the cross-chain relay node between the first blockchain network and the second blockchain network, wherein the first blockchain network maintains the first blockchain and the second blockchain network maintains the second blockchain. After obtaining the cross-chain processing transaction that has been recorded in the first blockchain and needs to be recorded in the second blockchain, the cross-chain relay node obtains the block validity proof queue. The block validity proof queue stores the block validity proof of each chained block according to the chaining order of the chained blocks on the first blockchain. The block validity proof is generated by the cross-chain relay node after the chained block is recorded in the first blockchain and stored in the block validity proof queue, so that the corresponding target block validity proof can be called at any time when the cross-chain processing transaction needs to be verified. The target block validity proof can prove that the target block corresponding to the cross-chain processing transaction is a valid block in the first blockchain. Based on the target block validity proof, a transaction validity proof can be generated, and the transaction validity proof can prove that the cross-chain processing transaction is a valid transaction in the valid block in the first blockchain. Therefore, after sending the transaction validity certificate to the second blockchain network, the second blockchain network can record the transaction to be processed across the chain into the second blockchain according to the transaction validity certificate. Through the above process, when verifying the security of the transaction to be processed across the chain, it is sufficient to directly call the pre-generated block validity certificate in the block validity certificate queue, and then generate the transaction validity certificate based on the block validity certificate, which greatly reduces the amount of data required to verify the validity of the block, and also greatly reduces the time required for multiple verifications. In this way, the embodiment of the present disclosure can improve the verification efficiency of the transaction to be processed across the chain, thereby improving the transaction processing efficiency across blockchains.

[0076] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] The accompanying drawings are used to provide further understanding of the technical solution of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the technical solution of the present disclosure and do not constitute a limitation on the technical solution of the present disclosure.

[0078] Figure 1A-1B is a system architecture diagram of a cross-blockchain transaction processing method application according to an embodiment of the present disclosure;

[0079] Figure 2A-2F It is a schematic diagram of a cross-blockchain transaction processing method according to an embodiment of the present disclosure applied to a scenario where a parent chain network performs cross-chain transaction collaborative processing on a child chain network;

[0080] Figure 3A-3H It is a schematic diagram of a cross-blockchain transaction processing method according to an embodiment of the present disclosure applied to a scenario of virtual resource transfer between different blockchains;

[0081] Figure 4 is a flowchart of a cross-blockchain transaction processing method according to an embodiment of the present disclosure;

[0082] Figure 5 yes Figure 4 A flowchart of step 410 in FIG.

[0083] Figure 6 Get a schematic diagram of the transactions to be processed across the chain;

[0084] Figure 7 It is a flow chart for generating on-chain transactions containing forwarding tags;

[0085] Figure 8 It is a schematic diagram of the transaction frame structure to be uploaded to the chain;

[0086] Fig. 9 yes Figure 5 A flowchart of step 520 in FIG.

[0087] Fig.10 It is a schematic diagram of storing transactions from the same first blockchain in the same transaction buffer pool;

[0088] Fig.11 yes Figure 5 A flowchart of step 520 in FIG.

[0089] Fig.12 This is a schematic diagram of the block validity proof queue;

[0090] Fig.13 It is a schematic diagram of the process of generating valid proof of blocks;

[0091] Fig.14 It is a flow chart for generating a block validity proof queue;

[0092] Fig.15 yes Fig.14 A flowchart of step 1420 in FIG.

[0093] Fig.16 This is a schematic diagram of verifying the validity of increasing blocks starting from block 0;

[0094] Fig.17 yes Fig.14 A flowchart of step 1420 in FIG.

[0095] Fig.18 yes Fig.17 A flowchart of step 1730 in FIG.

[0096] Fig.19 It is a schematic diagram of using the block verification algorithm to generate a block validity proof of adding blocks;

[0097] Fig. 20 yes Figure 4 A flowchart of step 430 in FIG.

[0098] Fig.21 yes Fig. 20 A flowchart of step 2010;

[0099] Fig. 22 This is a schematic diagram of the Merkle tree structure;

[0100] Fig.23 is another flowchart of a cross-blockchain transaction processing method according to an embodiment of the present disclosure;

[0101] Fig.24 yes Fig.23 A flowchart of step 2320 in FIG.

[0102] Fig.25 It is a flow chart of the second blockchain network registering the first blockchain network and the cross-chain relay node;

[0103] Fig.26 yes Fig.25 A specific schematic diagram of the flow chart of

[0104] Fig. 27 yes Fig.23 A flowchart of step 2330 in FIG.

[0105] Fig.28 is Fig.23 Then, a flow chart of the process of delivering transaction processing feedback message to the first blockchain network is added;

[0106] Fig.29 It is a detailed diagram of the overall implementation of the cross-blockchain transaction processing method of the embodiment of the present disclosure;

[0107] Fig.30 is a schematic diagram of the structure of a cross-blockchain transaction processing device according to an embodiment of the present disclosure;

[0108] Fig.31 is a structural schematic diagram of a cross-blockchain transaction processing device according to another embodiment of the present disclosure;

[0109] Fig.32 is a terminal structure diagram for implementing various methods according to an embodiment of the present disclosure;

[0110] Fig.33It is a server structure diagram for implementing various methods according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0111] In order to make the purpose, technical solution and advantages of the present disclosure more clear, the present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present disclosure and are not used to limit the present disclosure.

[0112] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:

[0113] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of transaction information, which is used to verify the validity of its information (anti-counterfeiting) and associate with the previous block.

[0114] Smart contract: It is a piece of code written on the blockchain. Once the terms of the execution contract are triggered in the blockchain at a certain time, the code will be automatically executed.

[0115] Hash function: A hash function is a public function whose main function is to map a message M into a shorter and fixed value H(M). It is an irreversible mapping from plaintext to ciphertext, with only encryption but no decryption process. The characteristics of the hash function ensure that for any two input combinations, there is a unique output value corresponding to them. This feature can be used to verify the properties of the input function parameters.

[0116] Merkle tree: It looks like a binary tree, and it is a full binary tree (a binary tree with the maximum number of nodes in each layer). At the bottom of the Merkle tree, the data is divided into small data blocks, and there are corresponding hashes corresponding to them. However, when going up, it does not directly calculate the root hash, but merges the two adjacent hashes into a string, and then calculates the hash of this string. Pushing up layer by layer, it is still the same way, and you can get a new level of hash with a smaller number, and eventually it will inevitably form an upside-down tree. At the root of the tree, there is only one hash value left at this level, which is the Merkle tree root.

[0117] Zero-knowledge proof: Zero-knowledge proof is a method of fully proving that one is the legal owner of certain rights without leaking relevant information - that is, the "knowledge" given to the outside world is "zero".

[0118] Trusted Execution Environment (TEE): Trusted Execution Environment is a hardware-based privacy computing solution. A secure area is built in the CPU through software and hardware methods to ensure that the programs and data loaded inside are protected in terms of confidentiality and integrity. TEE divides the system's hardware and software resources into two execution environments, the trusted part and the untrusted part. The two environments are isolated, and the untrusted part cannot access the storage and memory of the trusted part.

[0119] At present, more and more scenarios are beginning to use blockchain networks for transaction processing. Due to the decentralized nature of blockchain networks, which have the advantages of being difficult to attack and data being difficult to be tampered with, blockchain networks cannot directly transmit data with other blockchain networks. If a blockchain network wants to receive data from another blockchain network, it needs to verify the data from multiple aspects, such as the ownership relationship between the data and the blockchain, and the validity of the block where the data is located, to ensure the security of the data. In the prior art, in order to verify the security of the data to be processed, in addition to the need to transmit the data to be processed itself, it is also necessary to transmit the data of the entire blockchain. After receiving the data of the entire blockchain, starting from the 0th block, each block is verified one by one to see if it is connected to the previous block until the block where the data to be processed is verified. It can be seen that in order to verify the security of the data to be processed, the amount of data transmitted is very large, the verification time required is also long, and the verification efficiency is low, which leads to low efficiency in cross-chain transaction processing.

[0120] The disclosed embodiments can reduce the amount of data and verification time used for security verification, improve verification efficiency, and further improve cross-blockchain transaction processing efficiency.

[0121] System architecture and scenario description of the application of the embodiments of the present disclosure

[0122] Figure 1A It is a system architecture diagram applied by the cross-blockchain transaction processing method according to the embodiment of the present disclosure. It includes a first blockchain network, a cross-chain relay node and a second blockchain network, wherein the first blockchain network maintains multiple first blockchain nodes, and the second blockchain network maintains multiple second blockchain nodes.

[0123] The first blockchain network is the blockchain network that initiates the cross-chain transaction transmission request. When a transaction that also needs to be recorded in the second blockchain is recorded in a first blockchain of the first blockchain network, the first blockchain network needs to transmit this transaction to the cross-chain relay node.

[0124] After the second blockchain network receives the transaction validity proof from the cross-chain relay node, it records the transaction to be processed across the chain on the second blockchain according to the transaction validity proof.

[0125] The cross-chain relay node is the core processing unit of the cross-blockchain transaction processing method of the embodiment of the present disclosure, which is used to generate a transaction validity certificate for the transaction to be processed across the chain from the first blockchain to prove the validity of the transaction to be processed across the chain to the second blockchain network. The cross-chain relay node also stores a block validity certificate queue so that when generating a transaction validity certificate, the target block validity certificate corresponding to the transaction to be processed across the chain can be directly called. The cross-chain relay node and the first blockchain network can be in a corresponding relationship, that is, each first blockchain network has a corresponding cross-chain relay node to process the transaction to be processed across the chain. Each cross-chain relay node can also process transactions to be processed across the chain from multiple first blockchain networks.

[0126] Figure 1B It is another system architecture diagram applied by the cross-blockchain transaction processing method according to the embodiment of the present disclosure. It includes: a first blockchain network of the alliance chain, a second blockchain network and a cross-chain relay node. The first blockchain network of the alliance chain includes a first witness node and a first consensus node, wherein the first consensus node maintains a first blockchain that records transactions. The second blockchain network is used to record transactions from the first blockchain network. Therefore, after receiving the cross-chain transaction from the first blockchain, the second blockchain network can chain the transaction consensus in the second consensus network. The number of cross-chain relay nodes between the first blockchain network and the second blockchain network can be multiple. The first blockchain network can pass transactions to multiple cross-chain relay nodes at the same time, and the data and permissions in the multiple cross-chain relay nodes are exactly the same. Multiple cross-chain relay nodes collaborate to process cross-chain transactions to avoid the inability to transmit transactions after an abnormality occurs in a single cross-chain relay node.

[0127] The embodiments of the present disclosure can be applied in various scenarios, such as Figure 2A-2F The scenario shown in Figure 1 is that the parent chain network performs cross-chain transaction collaborative processing on the child chain network, which is similar to the following Figure 3A-3H Different blockchains shown are used for virtual resource transfer scenarios, etc.

[0128] (I) The sub-chain network performs cross-chain transaction collaborative processing on the parent chain network

[0129] In the field of blockchain, in order to make the blockchain system more flexible and scalable, another independent blockchain network can be established based on a main blockchain network. The main blockchain network is the parent chain, and the independent blockchain network established based on the parent chain is the child chain. The child chain can have its own consensus rules and characteristics, but it depends on the security and stability of the parent chain. Some transactions on the child chain require the parent chain network to coordinate and process. Figure 2AAs shown in Figure 1, a parent chain can connect multiple child chains. For example, Company A has multiple subsidiaries. Company A has an independent blockchain network, and each subsidiary also has its own independent blockchain network. The blockchain network of the subsidiary depends on the establishment of the blockchain network of Company A. Some transactions generated in the blockchain network of the subsidiary need to be transmitted to the blockchain network of Company A. For example, each subsidiary regularly counts the number of virtual resources in the resource pool and reports it to Company A, which is recorded in the parent chain network by Company A.

[0130] Although the sub-chain network is established based on the parent chain network, since the sub-chain network and the parent chain network are independent blockchain networks, verification is also required when the sub-chain network transmits data to the parent chain network. The transaction verification efficiency of the related technology is low. Figure 2B-2F shown. Figure 2B In the transaction processing application of subchain network A, the number of virtual resources transferred in and out of the resource pool of object a within a predetermined time period (such as one day or one week, etc.) is displayed. The total number of virtual resources transferred in is 220, and the total number of virtual resources transferred out is 55. This virtual resource quantity summary result has been recorded in subchain network A and needs to be uploaded to the parent chain network for record.

[0131] After clicking “Confirm Upload”, the interface of the transaction processing application of subchain network A is displayed as follows Figure 2C As shown, the interface displays "Submitted to subchain A, waiting for the cross-chain relay node to generate transaction validity proof..." In this process, the cross-chain relay node between subchain network A and the parent chain network obtains the above virtual resource quantity summary result; and obtains the block validity proof queue, from which the target block validity proof corresponding to the virtual resource quantity summary result is obtained; based on the target block validity proof, the transaction validity proof is obtained.

[0132] After generating the transaction validity proof, the interface of the transaction processing application of subchain network A is displayed as follows Figure 2D As shown in the figure, the interface shows "Transaction validity proof has been generated, waiting for the parent chain network to record the summary transaction..." In this process, the parent chain network records the summary transaction into its blockchain based on the transaction validity proof. After the recording is completed, Figure 2E As shown, the interface displays "The parent chain network has recorded the aggregated transaction".

[0133] In the parent chain network transaction processing application, the recorded and latest received transaction messages can be displayed. Figure 2F As shown, the transaction details of the summary transaction are displayed. The original total number of virtual resources in the resource pool of object a is 500. After recording the latest received summary transaction, the total number of virtual resources in the resource pool of object a is 665.

[0134] Through the above process, the transactions in the sub-chain network are transferred to the parent chain network for recording. Since in the process of generating transaction validity proof, the cross-chain relay node does not need to perform the block verification process, but can directly call the block validity proof generated in advance when recording the transaction. Therefore, the cross-blockchain transaction processing method of the embodiment of the present disclosure can improve the transaction verification efficiency, thereby improving the transaction processing efficiency.

[0135] (II) Virtual resource transfer scenarios of different blockchains

[0136] In the blockchain field, data can also be transmitted between completely independent blockchain networks, such as Figure 3A As shown. Blockchain network A-blockchain network D are completely independent blockchain networks. Data can be transmitted between any two blockchain networks. However, in order to ensure the security of the blockchain network, the transmitted data needs to be strictly verified. Figure 3B-3H What is shown is the process of transferring virtual resources between different blockchains. Figure 3B In the transaction processing application of blockchain network A, the number of virtual resources of object B is displayed as 1000. In the application, you can choose to transfer resources within the blockchain network or across blockchain networks.

[0137] After selecting "Cross-Blockchain Transfer", Figure 3C As shown in the figure, fill in the transfer details in the interface, where the resource transfer quantity is 300, the transfer object is "Object C", and the target blockchain network is "Blockchain Network B". After clicking "Confirm Transfer", Figure 3D As shown in the figure, the interface shows "Blockchain network A is recording resource transfer transactions..." When transferring virtual resources, the number of virtual resources recorded in blockchain network A needs to be adjusted before transferring to blockchain network B. After blockchain network A completes the recording, Figure 3E As shown in the figure, the interface shows "The cross-chain relay node is generating a transaction validity certificate". In this process, after the cross-chain relay node obtains the virtual resource transfer transaction, it obtains the target block validity certificate corresponding to the transaction in the block validity certificate queue, and then generates a transaction validity certificate based on the target block validity certificate, where the target block validity certificate is generated after the virtual resource transfer transaction is recorded in the blockchain network A and is generated along with the generation of the block. After generating the transaction validity certificate, as shown in the figure, Figure 3F As shown, the interface shows "Blockchain network B is recording resource transfer transactions." During this process, blockchain network B processes resource transfer transactions based on transaction validity proof.

[0138] After blockchain network B successfully records the resource transfer transaction, Figure 3GAs shown, the interface of the transaction processing application of blockchain network A displays "Transfer Successful" and shows that the current number of virtual resources of object B is 700 (300 virtual resources are transferred out of 1000). Figure 3H As shown, the interface of the transaction processing application of blockchain network B displays "Virtual resource transfer received from blockchain network A" and displays the change in the number of virtual resources before and after the transaction is processed. Before processing the virtual resource transfer transaction, the number of virtual resources of object C is 500. After receiving 300 virtual resources from object B, the current number of virtual resources of object C is 800.

[0139] Through the above process, the transaction verification efficiency is improved in the process of virtual resource transfer across blockchain networks. Therefore, the cross-blockchain transaction processing method of the disclosed embodiment is applied in the scenario of virtual resource transfer between different blockchains, which can improve the transaction processing efficiency while ensuring the security of transaction processing.

[0140] General description of the cross-blockchain transaction processing method on the cross-chain relay node side

[0141] According to an embodiment of the present disclosure, a cross-blockchain transaction processing method is provided. The method can be used for cross-chain transaction processing between different blockchain networks, specifically, for example Figure 2A-2F The parent chain network shown in the figure performs cross-chain transaction coordination with the child chain network. Figure 3A-3H Different blockchains shown are used for scenarios such as virtual resource transfer.

[0142] Since there is data isolation between different blockchain networks, in order to ensure the security of blockchain networks, transactions need to be verified when cross-chain transactions are processed between different blockchain networks. Currently, in one method, it is necessary to obtain the complete data of the blockchain where the transaction is located to verify the transaction, and verify it one by one from the first block in the blockchain until the block where the transaction is located. This process can accurately prove that the block where the transaction is located is a valid block in the blockchain. However, this process requires a large amount of data to be transmitted, and the amount of calculation required for verification is large, and the verification efficiency is low. Under the premise of ensuring the accuracy of verification, the disclosed embodiment reduces the amount of data required for verification, improves the verification efficiency, and thus improves the efficiency of cross-chain transaction processing.

[0143] The cross-blockchain transaction processing method provided by the embodiments of the present disclosure can be applied to a cross-chain relay node between a first blockchain network and a second blockchain network, wherein the first blockchain network maintains a first blockchain and the second blockchain network maintains a second blockchain.

[0144] like Figure 4 As shown, according to one embodiment of the present disclosure, a cross-blockchain transaction processing method includes:

[0145] Step 410: Obtain the transaction to be processed across the chain;

[0146] Step 420: Obtain block validity proof queue;

[0147] Step 430: Obtain the target block validity certificate corresponding to the transaction to be processed across the chain from the block validity certificate queue, and generate the transaction validity certificate based on the target block validity certificate;

[0148] Step 440: Send the transaction validity certificate to the second blockchain network so that the second blockchain network records the transaction to be processed across the chain to the second blockchain based on the transaction validity certificate.

[0149] Steps 410 to 440 are described in detail below.

[0150] Detailed description of step 410

[0151] In step 410, a transaction to be processed across the chain is obtained. The transaction to be processed across the chain is a transaction that has been recorded in the first blockchain and needs to be recorded in the second blockchain.

[0152] In one embodiment, obtaining the transaction to be cross-chain processed includes: responding to a cross-chain processing request of an on-chain transaction in the first blockchain, determining the on-chain transaction in the cross-chain processing request as the transaction to be cross-chain processed.

[0153] In this embodiment, the first blockchain network may include a cross-chain request generation contract. If an on-chain transaction in the first blockchain has a cross-chain processing requirement, then in response to an instruction for cross-chain processing of the transaction, the cross-chain request generation contract is called to generate a cross-chain processing request corresponding to the transaction.

[0154] The cross-chain processing request contains the on-chain transactions that need to be processed across the chain. When the cross-chain relay node receives the cross-chain processing request from the first blockchain network, it will treat the on-chain transactions as transactions to be processed across the chain. When the first blockchain network generates multiple cross-chain processing requests at the same time, or multiple first blockchain networks generate multiple cross-chain processing requests, the cross-chain relay node can process the multiple cross-chain processing requests in the order in which the on-chain transactions are on the chain in the first blockchain network. The cross-chain processing request can also include a transaction priority, which can be determined by the cross-chain request generation contract based on multiple aspects such as the transaction type and the urgency of the transaction when generating the cross-chain processing request. Multiple cross-chain processing requests obtained at the same time can also be processed in the order of transaction priority.

[0155] The cross-chain relay node obtains the pending cross-chain processing transactions from the received cross-chain processing requests, which makes it easier for the cross-chain relay node to manage the pending cross-chain processing transactions based on the cross-chain processing requests, and is conducive to improving the orderliness of the cross-chain relay node in processing the pending cross-chain processing transactions.

[0156] In another embodiment, if Figure 5 As shown, obtain the transactions to be processed across the chain, including:

[0157] Step 510: Obtain the transactions on the first blockchain.

[0158] Step 520: Obtain the transaction to be processed across the chain from the on-chain transaction that contains the forwarding tag.

[0159] In this embodiment, the forwarding tag is a tag added by the first blockchain network to the transaction that needs to be forwarded to the second blockchain network. The cross-chain relay node obtains the chained transactions in the first blockchain in real time, and when the chained transactions containing the forwarding tag are identified, the transactions to be processed across the chain are obtained. Specifically, the real-time acquisition of the chained transactions in the first blockchain can be that when a new block is added to the first blockchain, the cross-chain relay node obtains the chained transactions in the newly added block. The process of the cross-chain relay node identifying the forwarding tag does not need to obtain the specific content of the chained transaction, but only needs to determine whether the chained transaction contains the forwarding tag.

[0160] The process of obtaining transactions to be processed across chains is as follows: Figure 6 As shown, when a first blockchain in the first blockchain network adds a new block C, the cross-chain relay node obtains the on-chain transactions in block C. Block C contains transactions a-d, where transaction b contains a forwarding mark. Therefore, transaction b is obtained as the transaction to be processed across the chain.

[0161] In one embodiment, Figure 7 As shown, the on-chain transaction containing the forwarding tag is generated in the first blockchain network in the following manner:

[0162] Step 710: Obtain the transaction to be uploaded to the chain, and determine the first transaction type of the transaction to be uploaded to the chain;

[0163] Step 720: Obtain a transaction processing contract corresponding to the first transaction type;

[0164] Step 730: If the transaction to be on-chain meets the predetermined forwarding conditions in the transaction processing contract, the transaction processing contract adds a forwarding tag to the transaction to be on-chain, records the transaction to be on-chain in the first blockchain, and generates an on-chain transaction containing the forwarding tag.

[0165] The transactions processed by the first blockchain network may include multiple transaction types, such as virtual resource transfer transactions, resource aggregation transactions, and resource data protection. For each transaction type to be on-chained, the first blockchain network includes a corresponding transaction processing contract. The transaction processing contract processes transactions according to the processing rules of the corresponding transaction type.

[0166] In this embodiment, when obtaining the transaction to be put on the chain, the first blockchain network determines the first transaction type of the transaction to be put on the chain. The frame structure of the transaction to be put on the chain obtained by the first blockchain network can be as follows: Figure 8 As shown, it includes: transaction subject, transaction type, initiator address and timestamp. The transaction subject is the core content of the transaction, for example, the target object and transfer quantity when transferring virtual resources. The transaction type is the specific type of the transaction to be chained. The transaction type that can be processed by each first blockchain network can be represented by a transaction type identifier. For example, the transaction type and corresponding identifier that can be processed by a first blockchain network are {virtual resource transfer class: 01, resource aggregation class: 02, resource data protection class: 03}. If the transaction to be chained is a virtual resource transfer transaction, then the transaction type in the frame structure is "01". The initiator address can be the address of the device that initiates the transaction to be chained. The timestamp can be the time point when the transaction to be chained is initiated. Therefore, based on the above frame structure, the first blockchain network can directly determine the corresponding first transaction type through the acquired transaction to be chained.

[0167] Since each first transaction type corresponds to a transaction processing contract in the first blockchain network, after determining the first transaction type, the corresponding transaction processing contract is called to perform transaction processing.

[0168] When a transaction processing contract processes a transaction to be on-chain that meets the predetermined forwarding conditions, it will add a forwarding tag to the transaction while recording the transaction to be on-chain. The predetermined forwarding conditions refer to the conditions that must be met for cross-chain processing of transactions. The predetermined forwarding conditions may be different in transaction processing contracts of different transaction types. For example, virtual resource transfer transactions are divided into cross-blockchain network virtual resource transfers and blockchain network internal virtual resource transfers. Therefore, the predetermined forwarding conditions in the virtual resource transfer transaction processing contract are: the transaction to be on-chain is a cross-blockchain network virtual resource transfer transaction. For another example, resource aggregation transactions can be aggregated according to time periods and then processed across chains. Therefore, the predetermined forwarding conditions in the resource aggregation transaction processing contract can be: the aggregation period is one month. If the resource aggregation transaction processing contract processes resource aggregation transactions within a week, no forwarding tag will be added.

[0169] When the transaction to be on-chain meets the predetermined forwarding conditions in the corresponding transaction processing contract, the transaction processing contract will add a forwarding mark to the transaction to be on-chain, and record the transaction to be on-chain in the first blockchain to obtain an on-chain transaction containing the forwarding mark.

[0170] In this embodiment, transaction processing contracts of different transaction types are used to add forwarding tags to transactions to be on the chain that meet predetermined forwarding conditions. Forwarding conditions can be customized in transaction processing contracts of different transaction types, and forwarding tags can be automatically added to transactions to be on the chain. There is no need to manually determine whether each transaction to be on the chain needs to be processed across the chain, which improves the flexibility of adding forwarding tags and transaction processing efficiency.

[0171] Obtaining the transactions to be processed across the chain from the on-chain transactions that include a forwarding tag may be to directly use each on-chain transaction that includes a forwarding tag as a transaction to be processed across the chain for subsequent cross-chain transaction processing.

[0172] In another embodiment, Fig. 9 As shown, in the on-chain transaction containing the forwarding tag, the transaction to be processed across the chain is obtained, including:

[0173] Step 910: Store the on-chain transaction containing the forwarding tag in the transaction buffer pool;

[0174] Step 920: After the transactions in the transaction buffer pool meet the predetermined conditions, the transactions in the transaction buffer pool are taken out as transactions to be processed across the chain.

[0175] In this embodiment, after the cross-chain relay node obtains the on-chain transaction containing the forwarding mark, it will store the on-chain transaction in the transaction buffer pool. The transaction buffer pool is used to temporarily store the on-chain transaction containing the forwarding mark. When the transactions in the transaction buffer pool meet the predetermined conditions, the transactions therein are used as transactions to be processed across the chain. The reason for using the transaction buffer pool to cache transactions is that when the cross-chain relay node obtains multiple on-chain transactions containing forwarding marks, if the multiple on-chain transactions are directly used as transactions to be processed across the chain for subsequent cross-chain transaction processing, it may cause congestion in the processing thread of the cross-chain relay node and reduce the efficiency of transaction processing. Therefore, using the transaction buffer pool to cache the on-chain transactions containing forwarding marks can manage transactions in batches, and orderly treat transactions as transactions to be processed across the chain and process them.

[0176] The predetermined condition may be that the on-chain transactions in the transaction buffer pool reach a predetermined value, for example, the transactions in the transaction buffer pool reach 10; or the storage time of the transaction buffer pool reaches a predetermined time period, for example, the transaction buffer pool takes out transactions as transactions to be processed across the chain every 5 minutes.

[0177] There may be multiple transaction buffer pools in a cross-chain relay node, which are used to divide different on-chain transactions into different transaction buffer pools. The division of different on-chain transactions into different transaction buffer pools may be based on the first blockchain where the on-chain transactions are located. Since in the subsequent step 420, the block validity proof queue corresponding to the first blockchain where the transaction to be processed across the chain is located is obtained, the on-chain transactions are divided into different transaction buffer pools according to the first blockchain where they are located, so that after taking out transactions from the transaction buffer pool as transactions to be processed across the chain, the block validity proof queue corresponding to the first blockchain can be obtained for multiple transactions to be processed across the chain from the same first blockchain.

[0178] For example Fig.10 As shown, transactions x_a, x_b, and x_c from the first blockchain X are stored in transaction buffer pool A. When the transactions in transaction buffer pool A meet the predetermined conditions, transactions x_a, x_b, and x_c are taken out as transactions to be processed across the chain for batch processing. Since all these transactions are from the first blockchain X, when batch processing is performed, it is only necessary to call the block valid proof queue x corresponding to the first blockchain X. Similarly, transactions y_a and y_b from the first blockchain Y are stored in transaction buffer pool B. After the transactions are taken out as transactions to be processed across the chain, it is only necessary to call the block valid proof queue y corresponding to the first blockchain Y; transactions z_a, z_b, and z_c from the first blockchain Z are stored in transaction buffer pool C. After the transactions are taken out as transactions to be processed across the chain, it is only necessary to call the block valid proof queue z corresponding to the first blockchain Z. In this way, for multiple transactions to be processed across chains from the same first blockchain, it is possible to call the corresponding block validity proof queue only once, thereby saving the time of repeatedly obtaining the block validity proof queue and improving the efficiency of cross-chain transaction processing.

[0179] For multiple transaction buffer pools in a cross-chain relay node, transactions can be queued for processing in the order in which they meet the predetermined conditions. Multiple threads can also be included in the cross-chain relay node to achieve synchronous processing of multiple transaction buffer pools to improve cross-chain processing efficiency.

[0180] In the embodiment of step 910-step 920, using the transaction buffer pool to cache the on-chain transactions containing forwarding identifiers can avoid the problem of thread congestion caused by the cross-chain relay node simultaneously obtaining multiple transactions to be processed across the chain, which is beneficial for the cross-chain relay node to batch manage the obtained transactions to be processed across the chain, thereby improving the cross-chain transaction processing efficiency of the cross-chain relay node.

[0181] The transaction buffer pool needs to cache transactions in batches before orderly cross-chain processing. However, for some urgent cross-chain transactions, if the transactions are cached in the transaction buffer pool and then taken out after the transactions in the transaction buffer pool meet the predetermined conditions, the processing progress of the transactions may be affected. Therefore, in another embodiment, Fig.11 As shown, in the on-chain transaction containing the forwarding tag, the transaction to be processed across the chain is obtained, including:

[0182] Step 1110: If the forwarding mark of the on-chain transaction is an immediate forwarding mark, the on-chain transaction is obtained as a transaction to be processed across the chain;

[0183] Step 1120: If the forwarding mark of the on-chain transaction is a cache forwarding mark, the on-chain transaction is stored in the transaction buffer pool. After the transactions in the transaction buffer pool meet the predetermined conditions, the transactions in the transaction buffer pool are taken out as transactions to be processed across the chain.

[0184] In this embodiment, the forwarding mark of the chained transaction is divided into two types, namely, an immediate forwarding mark and a cache forwarding mark. The chained transaction containing the immediate forwarding mark is a transaction that needs to be processed across the chain as soon as possible, and can be directly used as a transaction to be processed across the chain.

[0185] The on-chain transaction containing the cache forwarding identifier is a transaction that can be processed delayed. In order to ensure that the cross-chain relay node can process transactions in an orderly and efficient manner, the on-chain transaction containing the cache forwarding identifier can be cached in the transaction buffer pool. After the transaction in the transaction buffer pool meets the predetermined conditions, the transaction in the transaction buffer pool is taken out as the transaction to be processed across the chain. The process of using the transaction buffer pool to cache and then take out transactions is the same as the above embodiment, and will not be repeated here.

[0186] In this embodiment, different processing methods can be implemented for on-chain transactions with different forwarding marks, while ensuring that the cross-chain relay node can manage the transactions to be processed across the chain in an orderly and efficient manner, and there is a priority channel for transactions that need to be forwarded immediately. Therefore, this embodiment improves the flexibility of transaction processing while ensuring the efficiency of cross-chain relay nodes in cross-chain transaction processing.

[0187] In the embodiment of step 510-step 520, the cross-chain relay node actively obtains the on-chain transactions in the first blockchain, and obtains the transactions to be processed across the chain through the on-chain transactions containing the forwarding mark. Through this process, the transactions to be processed across the chain can be quickly obtained, which improves the efficiency of obtaining the transactions to be processed across the chain.

[0188] Detailed description of step 420

[0189] In step 420, a block validity proof queue is obtained. The block validity proof queue stores the block validity proofs of the chained blocks in the order in which the chained blocks are chained on the first blockchain. Fig.12 As shown, each block in a first blockchain has a corresponding block validity certificate, and the block validity certificates are arranged in the block validity certificate queue according to the order in which the corresponding blocks are on the first blockchain. The block validity certificate queue is stored on the cross-chain relay node. Therefore, the cross-chain relay node can directly retrieve the locally stored block validity certificate queue corresponding to the transaction to be processed across the chain in the first blockchain when obtaining the block validity certificate queue.

[0190] The block validity proof of the chained block is used to prove that the block is a valid block in the first blockchain. When the 0th block in the first blockchain can be verified to a chained block in the blockchain structure, and this chained block is chained based on the consensus rules of the first blockchain network, then this chained block is a valid block in the first blockchain. The block validity proof of the chained block is generated by the cross-chain relay node when the chained block is recorded in the first blockchain and is placed in the block validity proof queue. Fig.13 As shown, when block 000 is generated in the first blockchain, the cross-chain relay node generates block validity proof 000 of block 000, and generates a block validity proof queue corresponding to the first blockchain; when block 001 is added to the first blockchain, the cross-chain relay node generates the corresponding block validity proof 001 and puts it into the block validity proof queue; similarly, the block validity proof 002 corresponding to the newly added block 002 is generated and put into the block validity proof queue, and so on.

[0191] Specifically, in one embodiment, Fig.14 As shown, the block validity proof queue is pre-generated in the following way:

[0192] Step 1410: Obtain the added block added to the first blockchain;

[0193] Step 1420: Verify the added block using a block verification algorithm to generate a block validity certificate for the added block;

[0194] Step 1430: Record the block validity certificate into the block validity certificate queue according to the block height of the added block in the first blockchain.

[0195] In step 1410 of this embodiment, when an additional block is added to a first blockchain in the first blockchain network, the cross-chain relay node can receive the additional block sent by the first blockchain network.

[0196] In step 1420, the added block is verified using a block verification algorithm to generate a block validity certificate for the added block. The block validity certificate is used to prove that the added block can be verified from the 0th block of the first blockchain in a block chain structure. Therefore, in one embodiment, Fig.15 As shown, the block verification algorithm is used to verify the added block and generate a valid block proof of the added block, including:

[0197] Step 1510: Obtain the block header of each block in the first blockchain where the added block is located;

[0198] Step 1520: Starting from the block header of the 0th block, verify the block headers one by one in the order in which the blocks are added to the chain;

[0199] Step 1530: If all block headers from the first block to the added block are successfully verified, a block validity certificate for the added block is generated.

[0200] In this embodiment, the first blockchain where the added block is located is determined, and the block header of each block in the first blockchain is obtained.

[0201] Since the block header of each block contains the block digest value of the parent block and the digest value of the current block, the block headers are verified one by one in the order of the blocks being uploaded to the chain, starting from the 0th block header, including: taking the 0th block header as the current block header and obtaining the current block digest value; if the current block digest value is equal to the parent block digest value of the next block header, the verification is passed and the next block header is taken as the current block header. Fig.16 As shown in the figure, if the block digest value in the block header of block 0 is equal to the parent block digest value in the block header of block 1, it can be proved that block 1 is a valid block connected to block 0 in a block chain structure; if the block digest value in the block header of block 1 is equal to the parent block digest value in the block header of block 2, block 2 is a block connected to block 1 in a block chain structure, and it can be proved that block 2 is a valid block connected to block 0 in a block chain structure. Similarly, if it can be proved that the added block is a block connected to the previous block in a block chain structure, then it can be proved that the added block is a valid block connected to block 0 in a block chain structure. Therefore, if all the block headers from block 1 to the added block are successfully verified, a block validity certificate of the added block is generated.

[0202] This embodiment verifies from the 0th block in the first blockchain to the added block. If the verification is successful, a block validity certificate of the added block is generated, thereby improving the accuracy of block verification.

[0203] Although the block headers of all blocks in the first blockchain are used for block verification, the verification accuracy is high, but the amount of data transmitted for each block verification is large, and the verification efficiency is low. Fig.17 As shown, the block verification algorithm is used to verify the added block and generate a valid block proof of the added block, including:

[0204] Step 1710: Obtain a first block header of the added block and a second block header of a block before the added block;

[0205] Step 1720: Perform block header verification based on the first block header and the second block header;

[0206] Step 1730: If the block header verification succeeds, and the previous block certificate corresponding to the previous block height of the added block is obtained from the block validity certificate queue, a block validity certificate for the added block is generated.

[0207] In this embodiment, the first block header of the added block and the second block header of the previous block of the added block in the first blockchain are obtained. Block header verification is performed based on the first block header and the second block header.

[0208] In one embodiment, the first block header includes a first block digest of a previous block, and the second block header includes a second block digest of the previous block; based on the first block header and the second block header, block header verification is performed, including: if the first block digest is the same as the second block digest, determining that the block header verification is successful.

[0209] Similar to the process of verifying the block header of the next block based on the block header of the current block in the aforementioned embodiment, the first block digest is the parent block digest value in the first block header of the added block, and the second block digest is the block digest value in the second block header of the previous block. Therefore, if the first block digest is equal to the second block digest, it can be proved that the added block is a block connected to the block chain of the previous block.

[0210] In this embodiment, the first block digest and the second block digest are used to verify the block header, thereby improving the accuracy of block header verification.

[0211] If the block header verification succeeds, obtain the block validity certificate of the previous block height of the added block from the block validity certificate queue. Since the block validity certificate can prove that the previous block is a valid block connected to the 0th block in a block chain structure, if the block validity certificate of the previous block can be obtained, it can be proved that the added block is a valid block connected to the 0th block in a block chain structure, and then generate a block validity certificate for the added block.

[0212] In one embodiment, Fig.18As shown, if the block header verification succeeds, and the previous block proof corresponding to the previous block height of the added block is obtained from the block validity proof queue, a block validity proof of the added block is generated, including:

[0213] Step 1810: If the block header verification succeeds, and the previous block certificate corresponding to the previous block height of the added block is obtained from the block valid certificate queue, then the first signature of the first blockchain network recording the added block and the first key of the first blockchain network are obtained;

[0214] Step 1820: decrypt the first signature using the first key to obtain a decryption result;

[0215] Step 1830, calculate the digest of the added block, and compare the digest with the decryption result;

[0216] Step 1840: If the digest is consistent with the decryption result, a block validity certificate for the added block is generated.

[0217] It can be seen from the above embodiments that if the block header verification is successful, and the previous block proof corresponding to the previous block height of the added block is obtained from the block valid proof queue, then it can be proved that the added block is a block connected to the 0th block in a block chain structure. In order to further improve the accuracy of the verification result of the added block, in this embodiment, the first signature of the first blockchain network that records the added block and the first key of the first blockchain network are obtained.

[0218] When the added block is consensus-uploaded in the first blockchain network, the first blockchain network will sign the added block to indicate that the added block is recorded in the first blockchain after consensus among the consensus nodes in the first blockchain network. The process of signing the added block can be to encrypt the summary of the added block. Therefore, the first signature of the first blockchain network that records the added block can be obtained in the block header of the added block.

[0219] After generating the first signature of the added block, the added block can obtain the first key for signature verification, and the first key obtained by each block in the first blockchain network can be the same. Therefore, in order to avoid the first key of the added block being incorrect, the first key of the previous block of the added block can be obtained to verify the added block. Since the previous block of the added block has been proven to be a valid block in the first blockchain, the first key of the previous block is correct and can be used to verify the security of the added block.

[0220] After obtaining the first signature and the first key, the first signature is decrypted using the first key, and the decrypted result is the digest value of the added block before it is encrypted. Then the digest of the added block is calculated. If the digest value obtained by decryption is the same as the digest value obtained after calculation, it can be proved that the added block was put on the chain after consensus by the consensus nodes of the first blockchain network. Therefore, a block validity certificate of the added block can be generated.

[0221] In this embodiment, the process of generating a block validity certificate is as follows: Fig.19 As shown, the first block header of the added block, the second block header of the previous block of the added block, the block validity proof of the previous block and the first key of the previous block are input into the block verification algorithm. After successful verification, the block validity proof of the added block can be obtained. This block verification algorithm is a zero-knowledge proof algorithm. It does not need to obtain the transaction data stored in the block to realize the validity verification of the added block, which improves the data security of the block transaction during the verification process.

[0222] This embodiment generates a block validity certificate for the added block after proving that the added block is a block connected to the 0th block in a block chain structure and that the added block is on the chain after consensus by the consensus nodes of the first blockchain network. Through the above two-fold verification, the validity of the added block is proved in terms of the blockchain structure and the block consensus on-chain process, which improves the accuracy of generating a block validity certificate for the added block.

[0223] In the embodiment of step 1710-step 1730, the connection relationship between the added block and the previous block is verified by using the block header proof of the added block and the previous block, and then the validity of the added block is verified by obtaining the block validity proof of the previous block. While ensuring the accuracy of block verification, the amount of data calculated during the verification process is reduced, thereby improving the verification efficiency of block verification.

[0224] In step 1430, the generated block validity certificate is recorded in the block validity certificate queue according to the block height of the added block in the first blockchain. For example, if the block height of the added block is 100, then the corresponding block validity certificate is ranked 100th in the block validity certificate queue.

[0225] In the embodiment of step 1410-step 1430, whenever a new block is added to the first blockchain, the cross-chain relay node will verify it, generate the corresponding block validity certificate, and record it in the block validity certificate queue according to the block height. The block validity certificate queue is expanded synchronously with the first blockchain, which improves the generation efficiency of the block validity certificate queue.

[0226] Detailed description of step 430

[0227] In step 430, the target block validity certificate corresponding to the transaction to be processed across the chain is obtained from the block validity certificate queue, and the transaction validity certificate is generated based on the target block validity certificate.

[0228] The target block validity proof is a block validity proof of the target block corresponding to the transaction to be processed across the chain in the first blockchain. The transaction to be processed across the chain may include the block identifier of the target block corresponding to the transaction, and the cross-chain relay node may determine the target block corresponding to the transaction to be processed across the chain in the first blockchain according to the block identifier. The transaction validity proof is used to prove that the transaction to be processed across the chain is a valid transaction stored in the first blockchain. The condition that a valid transaction needs to meet is that the transaction to be processed across the chain is in a valid block stored in the first blockchain. Therefore, when it is proved that the target block where the transaction to be processed across the chain is located is a valid block in the first blockchain, a transaction validity proof of the transaction to be processed across the chain can be generated.

[0229] By obtaining the target block valid proof corresponding to the transaction to be processed across the chain from the block valid proof queue, it can be determined that the target block is a valid block in the first blockchain. Since in the block valid proof queue, the block valid proof is stored in the order of the blocks that have been chained to the first blockchain, the target block valid proof can be obtained based on the block height of the target block corresponding to the transaction to be processed across the chain. The transaction to be processed across the chain obtained by the cross-chain relay node may also include the block height of the target block, and the block valid proof at the corresponding position is obtained from the block valid proof queue according to the block height as the target block valid proof.

[0230] After obtaining the target block validity certificate, a transaction validity certificate can be generated based on the target transaction validity certificate. Since the target block corresponding to the block identifier carried in the cross-chain transaction is the block location where the cross-chain transaction should be stored in theory, and the cross-chain relay node cannot know whether the cross-chain transaction is really the transaction stored in the target block, nor can it determine whether the data of the cross-chain transaction has been tampered with. Therefore, in one embodiment, the block identifier of the target block is included in the cross-chain transaction, such as Fig. 20 As shown, the transaction validity proof is generated based on the target block validity proof, including:

[0231] Step 2010: In response to the target block validity proof, based on the block identifier, determine that the transaction to be processed across the chain is located in the target block;

[0232] Step 220: Generate a transaction validity certificate based on the target block validity certificate and the relationship between the transaction to be processed across the chain and the target block.

[0233] In this embodiment, after the cross-chain relay node obtains the target block validity certificate from the block validity certificate queue, it determines whether the transaction to be processed across the chain is located in the target block in response to the target block validity certificate.

[0234] In one embodiment, Fig.21 As shown, based on the block identifier, determining that the transaction to be processed across the chain is located in the target block includes:

[0235] Step 2110: Based on the block identifier, obtain the Merkle tree root to be verified of the target block and the bypass summary value for verification of the transaction to be processed across the chain in the target block;

[0236] Step 2120: Determine to recalculate the Merkle tree root based on the transaction to be processed across chains and the bypass digest value for verification;

[0237] Step 2130: If the Merkle tree root to be verified is the same as the recalculated Merkle tree root, it is determined that the transaction to be processed across the chain is located in the target block.

[0238] When the first blockchain network generates a block, it will generate a Merkle tree of the block. The Merkle tree of the block is generated based on the summary value of each transaction in the block. Fig. 22 As shown in the figure, a block contains transactions a-h. For each transaction, the corresponding digest a-h can be obtained by using the hash algorithm to calculate the digest. Next, the digests of two adjacent nodes are hashed layer by layer, including: hashing digest a and digest b to obtain node A; hashing digest c and digest d to obtain node B; hashing digest e and digest f to obtain node C; hashing digest g and digest h to obtain node D; hashing node A and node B to obtain node E; hashing node C and node D to obtain node F; and finally hashing node E and node F to obtain the root node. The value of the root node is generated based on all transactions in the block. If the data of any transaction in the block is tampered with, the value of the root node will change.

[0239] Based on the concept of Merkle tree, in this embodiment, according to the block identifier carried in the cross-chain transaction to be processed, the Merkle tree root to be verified of the target block and the bypass digest value for verification of the cross-chain transaction to be processed in the target block are obtained. The Merkle tree root to be verified is the root of the Merkle tree corresponding to the target block. The bypass digest value for verification is the digest value of other transactions in the target block except the cross-chain transaction to be processed. For example, Fig. 22 In the example, transaction a is the transaction to be processed across the chain, then digest b-digest h is the bypass digest value for verifying the transaction to be processed across the chain.

[0240] Based on the transaction to be processed across the chain and the bypass digest value for verification, the recalculated Merkle root is determined, including: calculating the digest value of the transaction to be processed across the chain; calculating the recalculated Merkle root according to the digest value of the transaction to be processed across the chain and the bypass digest value for verification. The recalculated Merkle root is determined based on the digest value of the transaction to be processed across the chain obtained by the cross-chain relay node and the digest values ​​of other transactions in the Merkle tree to be verified except for the transaction to be processed across the chain, while the digest values ​​of other transactions have not changed. Therefore, by comparing the Merkle root to be verified with the recalculated Merkle root, if the two are inconsistent, it means that the digest value calculated according to the transaction to be processed across the chain is different from the digest value corresponding to the transaction to be processed across the chain stored when the target block is generated, that is, the transaction data of the transaction to be processed across the chain has changed, and it cannot be proved that the transaction to be processed across the chain is located in the target block. On the contrary, if the two are consistent, it means that the summary value obtained by the cross-chain relay node based on the transaction to be processed across the chain is the same as the original summary value, which can prove that the transaction to be processed across the chain is located in the target block.

[0241] In this embodiment, the Merkle root is recalculated based on the summary value of the cross-chain transaction and the bypass summary value for verification, and compared with the Merkle root to be verified in the block; based on the comparison result, it is determined whether the cross-chain transaction is located in the target block. Since the Merkle root to be verified and the bypass summary value are both data that are difficult to be tampered with, the verification accuracy of the cross-chain transaction can be improved by verifying it in this way.

[0242] In step 220, after determining the ownership relationship between the transaction to be processed across the chain and the target block, if the transaction to be processed across the chain does not belong to the target block, the cross-chain processing process is terminated. If the transaction to be processed across the chain belongs to the target block, and the target block validity certificate can prove that the target block is a valid block in the first blockchain, then it can be proved that the transaction to be processed across the chain is a valid transaction in the first blockchain, and a transaction validity certificate can be generated.

[0243] In the embodiment of step 2010-step 2020, after determining that the target block is a valid block in the first blockchain, it is further determined that the transaction to be processed across the chain is a transaction located in the target block, thereby proving the validity of the transaction to be processed across the chain and improving the accuracy of generating transaction validity proof.

[0244] Detailed description of step 440

[0245] In step 440, the cross-chain relay node sends the transaction validity certificate to the second blockchain network. In addition to proving the validity of the cross-chain transaction, the transaction validity certificate also plays a role in transmitting the transaction to be processed across the chain. The transaction to be processed across the chain is included in the transaction validity certificate, so that the second blockchain network can record the transaction to be processed across the chain into the second blockchain based on the transaction validity certificate. The second blockchain network reaches consensus on the cross-chain transaction to be processed through the consensus node.

[0246] In order to ensure the data security of the transaction validity proof during the transmission process, in one embodiment, sending the transaction validity proof to the second blockchain network includes: encrypting the transaction validity proof using the first private key; and sending the encrypted transaction validity proof to the second blockchain network.

[0247] In this embodiment, the first private key is issued by the blockchain management contract after the cross-chain relay node is registered with the blockchain management contract stored on the second blockchain network. The blockchain management contract is used to manage external nodes that can communicate data with the second blockchain network. After the second blockchain network receives the registration request of the cross-chain relay node, the blockchain management contract will issue the first public key and the first private key to the cross-chain relay node, send the first private key to the cross-chain relay node, and store the first public key in the blockchain management contract of the second blockchain network. The first private key is used to encrypt the transaction validity certificate, and the first public key is used in the second blockchain network to authenticate and decrypt the cross-chain relay node that issued the transaction validity certificate. After the verification is passed, the transaction to be processed across the chain in the transaction validity certificate is recorded in the second blockchain.

[0248] In one embodiment, encrypting a transaction validity certificate using a first private key includes:

[0249] Generate the string to be verified using a random string generation algorithm;

[0250] Encrypt the character string to be verified using the first private key to obtain an encrypted character string;

[0251] The transaction validity proof is encrypted using the first private key to obtain the encrypted transaction validity proof.

[0252] Sending the encrypted transaction validity certificate to the second blockchain network includes: sending the encrypted transaction validity certificate, the character string to be verified, and the encrypted random character string to the second blockchain network.

[0253] Based on the above process, the second blockchain network authenticates and decrypts the cross-chain relay node that issued the transaction validity proof in the following way:

[0254] Decrypting the encrypted string using the first public key to obtain a decrypted string;

[0255] If the decrypted string is the same as the string to be verified, the identity authentication of the cross-chain relay node is successful, and the encrypted transaction validity proof is decrypted using the first public key.

[0256] In this embodiment, a randomly generated string is used to assist in the identity authentication of the cross-chain relay node. For example, the string to be verified generated by the random string generation algorithm is "015acft6i", and the encrypted string obtained by encrypting it with the first private key is "5234". If the second blockchain network uses the first public key to decrypt the encrypted string and the result is "015acft6i", it means that the first private key and the first public key match each other, and the cross-chain relay node identity authentication is successful. Otherwise, the identity authentication fails.

[0257] Through the above process, the second blockchain network realizes the identity authentication of the cross-chain relay node without obtaining the specific data in the transaction validity proof, thereby improving the data security of the transaction validity proof.

[0258] Cross-blockchain transaction processing method on the second blockchain network side

[0259] According to one embodiment of the present disclosure, a cross-blockchain transaction processing method is also provided. The method can be applied to a second blockchain network.

[0260] like Fig.23 As shown, according to one embodiment of the present disclosure, a cross-blockchain transaction processing method includes:

[0261] Step 2310: Receive transaction validity proof from the cross-chain relay node;

[0262] Step 2320: Authenticate the identity of the cross-chain relay node based on the received transaction validity proof;

[0263] Step 2330: After the identity verification is successful, the transaction to be processed across the chain is recorded in the second blockchain.

[0264] This can be accomplished through a transaction verification processing contract in the second blockchain network. Steps 2310 to 2330 are described in detail below.

[0265] Detailed description of step 2310

[0266] In step 2310, the second blockchain network receives a transaction validity certificate from the cross-chain relay node. The transaction validity certificate is generated by the cross-chain relay node for the transaction to be processed across the chain, based on the ownership relationship between the transaction to be processed across the chain and the target block, and the block validity certificate of the target block, wherein the transaction to be processed across the chain has been recorded in the first blockchain of the first blockchain network and needs to be recorded in the second blockchain, and the block validity certificate is obtained from the block validity certificate queue, and the block validity certificate queue stores the block validity certificates of the chained blocks according to the chaining order of the chained blocks on the first blockchain. The block validity certificate is generated by the cross-chain relay node when the chained blocks are recorded in the first blockchain, and is placed in the block validity certificate queue.

[0267] The process of generating a transaction validity certificate has been described in detail in the aforementioned embodiment and will not be repeated here.

[0268] Detailed description of step 2320

[0269] In step 2320, the second blockchain network verifies the identity of the cross-chain relay node based on the received transaction validity proof to ensure that the data obtained from the cross-chain relay node is trustworthy.

[0270] In one embodiment, Fig.24 As shown, based on the received transaction validity proof, the identity of the cross-chain relay node is authenticated, including:

[0271] Step 2410: Obtain the first public key of the cross-chain relay node from the blockchain management contract;

[0272] Step 2420: Use the first public key to decrypt the transaction validity certificate, thereby authenticating the identity of the cross-chain relay node.

[0273] In this embodiment, the transaction validity proof is the transaction validity proof encrypted by the cross-chain relay node using the first private key. The first private key and the first public key are issued in pairs by the blockchain management contract after the cross-chain relay node is registered on the blockchain management contract stored on the second blockchain network. The blockchain management contract is used to manage external nodes that can communicate data with the second blockchain network. The external nodes include the first blockchain network, the cross-chain relay node, the verification node in the trusted execution environment, and the block header forwarding node. Among them, the verification node in the trusted execution environment is used to verify the data in a trusted security environment, and the block header forwarding node is used to provide a secure and trusted execution environment for the block header forwarding process in the cross-blockchain network data transmission process.

[0274] Since the cross-blockchain transaction processing method of the disclosed embodiment can be applied to the scenario where a cross-chain relay node processes transactions to be processed across multiple first blockchain networks, it can also be applied to the scenario where the cross-chain relay node corresponds to the first blockchain network one by one. Therefore, in an embodiment where a cross-chain relay node processes transactions to be processed across multiple first blockchain networks, the second blockchain network registers the cross-chain relay node in the following manner:

[0275] Get the node registration request from the cross-chain relay node;

[0276] The blockchain management contract is used to issue the first public key and the first private key to the cross-chain relay node.

[0277] In this embodiment, after receiving the node registration request from the cross-chain relay node, the second blockchain network assigns a relay node identifier to the cross-chain relay node, and then issues a first public key and a first private key to the cross-chain relay node.

[0278] In another embodiment, each first blockchain network corresponds to a cross-chain relay node. Fig.25 As shown, the second blockchain network registers the cross-chain relay node in the following way:

[0279] Step 2510: receiving a blockchain node registration request from a first blockchain network;

[0280] Step 2520: The blockchain management contract issues a first public key and a first private key to the cross-chain relay node corresponding to the first blockchain network;

[0281] Step 2520: Based on the blockchain node registration request, generate a blockchain verification contract corresponding to the first blockchain network.

[0282] In this embodiment, since the first blockchain network and the cross-chain relay node appear in pairs, the blockchain node registration request also includes the node address of the corresponding cross-chain relay node. After receiving the blockchain node registration request from the first blockchain network, the second blockchain network will register the corresponding cross-chain relay node while registering the first blockchain network.

[0283] The blockchain management contract will assign node identifiers to the first blockchain network and the cross-chain relay node, and then issue the first public key and the first private key to the cross-chain relay node. The first public key is stored in the blockchain management contract, and the first private key is sent to the cross-chain relay node.

[0284] The blockchain management contract also generates a blockchain verification contract for the first blockchain network. The blockchain verification contract is a dedicated verification contract of the first blockchain network in the second blockchain network, which is used to authenticate the identity of the cross-chain relay node using the first public key. When the second blockchain network authenticates the identity of the cross-chain relay node, it can call the blockchain verification contract corresponding to the cross-chain relay node. The blockchain verification contract can call the first public key of the cross-chain relay node from the blockchain management contract and use the first public key to verify the identity of the cross-chain relay node.

[0285] In this embodiment, the process of managing the first blockchain network and the cross-chain relay node by the blockchain management contract is as follows: Fig.26 As shown, the first blockchain network M corresponds to the cross-chain relay node N. When the second blockchain network receives the blockchain node registration request from the first blockchain network M, the blockchain management contract generates a first public key and a first private key, wherein the first private key is sent to the cross-chain relay node N. The blockchain management contract also generates a blockchain verification contract K corresponding to the first blockchain network M and the cross-chain relay node N. After the cross-chain relay node M sends the generated transaction validity certificate to the second blockchain network, the second blockchain network will call the blockchain verification contract K corresponding to the cross-chain relay node, and the blockchain verification contract will retrieve the first public key corresponding to the cross-chain relay node N in the blockchain management contract, and use the first public key to verify the identity of the cross-chain relay node.

[0286] In this embodiment, a blockchain verification contract is deployed for each first blockchain network and the corresponding cross-chain relay node, which prevents the identity authentication processes of different cross-chain relay nodes from interfering with each other, and is conducive to improving the efficiency and accuracy of the identity authentication of the cross-chain relay nodes.

[0287] The first public keys of multiple cross-chain relay nodes are stored in the blockchain management contract. In step 2410, the first public key of the cross-chain relay node is obtained from the blockchain management contract, and the corresponding first public key can be obtained based on the cross-chain relay node identifier assigned to the cross-chain relay node by the blockchain management contract when the cross-chain relay node is registered in the second blockchain network.

[0288] In step 2420, the transaction is decrypted with the first public key to verify the validity of the transaction, and the identity authentication of the cross-chain relay node is achieved during the decryption process. The process of decrypting with the first public key has been described in detail in the above embodiment and will not be repeated here.

[0289] In the embodiment of step 2410-step 2420, the first public key is used to authenticate the cross-chain relay node and decrypt the transaction validity proof, thereby improving the accuracy of authenticating the cross-chain relay node.

[0290] Detailed description of step 2330

[0291] In step 2330, the transaction to be processed across the chain in the decrypted transaction validity proof is taken out and recorded on the second blockchain.

[0292] Recording the transaction to be processed across the chain on the second blockchain can allow consensus on the transaction to be processed across the chain based on consensus rules in the second blockchain network.

[0293] Since the transactions received in the second blockchain network may be of various types, for example, virtual resource transfer transactions, resource aggregation transactions, and resource data protection transactions, etc. Therefore, in another embodiment, Fig. 27 As shown, after the identity authentication is successful, the transaction to be processed across the chain is recorded in the second blockchain, including:

[0294] Step 2710: After the identity verification is successful, obtain the second transaction type of the transaction to be processed across the chain;

[0295] Step 2720: call the transaction summary contract corresponding to the second transaction type to generate a summary transaction based on multiple transactions to be processed across chains of the second transaction type;

[0296] Step 2730: Record the summary transaction on the second blockchain.

[0297] In this embodiment, the process of obtaining the second transaction type of the transaction to be processed across the chain is similar to the process of determining the first transaction type of the transaction to be on-chain in the embodiment of steps 710 to 730, and will not be repeated here.

[0298] Each second transaction type corresponds to a transaction aggregation contract, which is used to aggregate multiple cross-chain transactions corresponding to the second transaction type to generate an aggregated transaction. The aggregated transactions are batch processed and recorded on the second blockchain according to the consensus rules of the second blockchain network.

[0299] For example, if the second transaction type of the transaction T to be processed across the chain is a virtual resource transfer transaction, the virtual resource transfer transaction summary contract is called and the transaction to be processed across the chain is submitted to the contract. The virtual resource transfer transaction summary contract summarizes multiple transactions to be processed across the chain, including the transaction T to be processed across the chain, whose second transaction type is virtual resource transfer, to generate a virtual resource transfer summary transaction. The virtual resource transfer summary transaction is recorded on the second blockchain based on the consensus rules in the second blockchain network.

[0300] The advantage of aggregating multiple transactions to be processed across the chain and recording them on the second blockchain based on the transaction aggregation contract corresponding to the second transaction type is that transactions to be processed across the chain of the same second transaction type can be processed in batches, thereby improving the processing efficiency of cross-chain transactions.

[0301] After recording the transaction to be processed across chains to the second blockchain, the processing result can be fed back to the first blockchain network. Fig.28 As shown, after step 2330, the following steps are also included:

[0302] Step 2810: Generate a transaction processing feedback message based on the record result of the transaction to be processed across the chain;

[0303] Step 2820: Send the transaction processing feedback message to the first blockchain network so that the first blockchain updates the forwarding status of the transaction to be processed across the chain.

[0304] After the second blockchain network records the transaction to be processed across the chain into the second blockchain, a transaction processing feedback message indicating successful recording is generated; if the second blockchain network fails to successfully record the transaction to be processed across the chain into the second blockchain, a transaction feedback message indicating failed recording is generated.

[0305] The transaction feedback message is sent to the first blockchain network. After receiving the transaction feedback message, the first blockchain network updates the forwarding status of the transaction to be processed across the chain. The forwarding status indicates whether the transaction to be processed across the chain is successfully recorded by the second blockchain. If the recording result in the transaction feedback message is a record failure, the transaction feedback message may also include the reason for the failure, for example, the identity authentication of the cross-chain relay node failed, or the transaction record failed. The first blockchain network can correct the transaction to be processed across the chain according to the reason for the failure, or check the cross-chain relay node so that the transaction to be processed across the chain can be initiated again and the transaction can be successfully recorded in the second blockchain. The first blockchain network can use the transaction cross-chain status confirmation contract to receive the transaction feedback message, and update the forwarding status of the transaction to be processed across the chain according to the transaction feedback message.

[0306] This embodiment uses transaction processing feedback messages to directly transmit transaction processing results to the first blockchain network without the need for cross-chain relay nodes, thereby improving message transmission efficiency.

[0307] Implementation details of the cross-blockchain transaction processing method of the disclosed embodiment

[0308] Refer to the following Fig.29 , the implementation details of the cross-blockchain transaction processing method of the embodiment of the present disclosure are explained in detail and by way of example.

[0309] In step 2901, the first blockchain network retrieves the corresponding transaction processing contract according to the first transaction type of the transaction to be on-chain.

[0310] In step 2902, the transaction processing contract adds a forwarding tag to the transaction to be chained that needs cross-chain processing. After the transaction to be chained is chained, the chained transaction containing the forwarding tag is obtained.

[0311] In step 2903, the first blockchain adds the added block to the chain.

[0312] In step 2904, the first blockchain transmits the block header of the added block, the block header of the previous block of the added block, and the first key to the cross-chain relay node.

[0313] In step 2905, the cross-chain relay node obtains the block validity certificate of the previous block in the block validity certificate queue corresponding to the first blockchain; generates a block validity certificate of the added block based on the block header of the added block, the block header of the previous block of the added block and the first key; and stores the block validity certificate into the block validity certificate queue according to the arrangement order of the blocks in the first blockchain.

[0314] In step 2906, the cross-chain relay node obtains the transactions to be processed across the chain in the first blockchain, that is, the on-chain transactions containing the forwarding mark.

[0315] In step 2907, the cross-chain relay node obtains the block validity proof queue, and obtains the target block validity proof corresponding to the transaction to be processed across the chain from the block validity proof queue.

[0316] In step 2908, the cross-chain relay node determines to recalculate the Merkle root based on the transaction to be processed across the chain and the bypass summary value for verification; if the Merkle tree root to be verified is the same as the recalculated Merkle root, it is determined that the transaction to be processed across the chain is located in the target block.

[0317] In step 2909, based on the target block validity proof and the relationship between the transaction to be processed across the chain and the target block, a transaction validity proof is generated.

[0318] In step 2910, the cross-chain relay node encrypts the transaction validity certificate using the first private key and transmits the encrypted transaction validity certificate to the second blockchain network. The first private key is registered by the cross-chain relay node on the blockchain management contract stored on the second blockchain network and issued by the blockchain management contract.

[0319] In step 2911, the transaction verification processing contract in the second blockchain network calls the corresponding blockchain verification contract based on the transaction validity proof. Each first blockchain network that can transmit data with the second blockchain network has a blockchain verification contract in the second blockchain network, which is deployed by the blockchain management contract in the second blockchain network when the first blockchain network is registered in the second blockchain network.

[0320] In step 2912, the blockchain verification contract retrieves the first public key of the cross-chain relay node. The first public key is issued in pairs with the first private key by the blockchain management contract.

[0321] In step 2913, the blockchain verification contract decrypts the transaction with the first public key to prove its validity and authenticate the cross-chain relay node.

[0322] In step 2914, the transaction verification contract determines the identity authentication result in the blockchain verification contract.

[0323] In step 2915, after identity authentication is successful, the transaction verification contract obtains the second transaction type of the transaction to be processed across the chain.

[0324] In step 2916, the transaction verification contract calls the transaction summary contract based on the second transaction type.

[0325] In step 2917, the transaction summary contract generates a summary transaction based on multiple transactions to be processed across the chain of the second transaction type, and records the summary transaction on the second blockchain.

[0326] In step 2918, the second blockchain network sends a transaction processing feedback message including the processing result of the transaction to be processed across the chain to the first blockchain network.

[0327] In step 2919, the transaction cross-chain status confirmation contract in the first blockchain network updates the forwarding status of the transaction to be cross-chain processed according to the transaction processing feedback message.

[0328] Description of the apparatus and device of the present disclosure

[0329] It is to be understood that, although the steps in the above-mentioned flowcharts are sequentially displayed according to the characterization of arrows, these steps are not necessarily executed in sequence according to the order of arrow characterization. Unless there is a clear description in the present embodiment, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the above-mentioned flowcharts can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0330] It should be noted that in each specific embodiment of the present disclosure, when it comes to the need to perform relevant processing based on data related to the characteristics of the target object such as the target object attribute information or attribute information set, the permission or consent of the target object will be obtained first, and the collection, use and processing of these data will comply with relevant laws, regulations and standards. In addition, when the embodiment of the present application needs to obtain the attribute information of the target object, the separate permission or separate consent of the target object will be obtained through a pop-up window or jump to a confirmation page. After clearly obtaining the separate permission or separate consent of the target object, the necessary target object-related data used to enable the normal operation of the embodiment of the present application is obtained.

[0331] Fig.30 A schematic diagram of the structure of a cross-blockchain transaction processing device 3000 located at a cross-chain relay node provided in an embodiment of the present disclosure. The cross-blockchain transaction processing device 3000 includes:

[0332] A first acquisition unit 3010 is used to acquire a transaction to be processed across the chain, wherein the transaction to be processed across the chain has been recorded in the first blockchain and needs to be recorded in the second blockchain;

[0333] The second acquisition unit 3020 is used to acquire a block validity proof queue, which stores block validity proofs of the chained blocks according to the chaining order of the chained blocks on the first blockchain, wherein the block validity proof of the chained block is generated by the cross-chain relay node performing block verification on the chained block when the chained block is recorded in the first blockchain and is placed in the block validity proof queue;

[0334] The first generating unit 3030 is used to obtain the target block validity certificate corresponding to the transaction to be processed across the chain from the block validity certificate queue, and generate the transaction validity certificate based on the target block validity certificate;

[0335] The first sending unit 3040 is used to send the transaction validity certificate to the second blockchain network, so that the second blockchain network records the transaction to be processed across the chain to the second blockchain based on the transaction validity certificate.

[0336] Optionally, the block validity proof queue is pre-generated by:

[0337] Obtaining the added block added to the first blockchain;

[0338] Use the block verification algorithm to verify the added block and generate a block validity certificate for the added block;

[0339] The block validity proof is recorded in the block validity proof queue according to the block height of the added block in the first blockchain.

[0340] Optionally, the added block is verified using a block verification algorithm to generate a block validity certificate for the added block, including:

[0341] Obtain the first block header of the added block and the second block header of the previous block of the added block;

[0342] Based on the first block header and the second block header, perform block header verification;

[0343] If the block header verification succeeds, and the previous block proof corresponding to the previous block height of the added block is obtained from the block validity proof queue, a block validity proof of the added block is generated.

[0344] Optionally, the first block header includes a first block digest of a previous block, and the second block header includes a second block digest of the previous block;

[0345] Based on the first block header and the second block header, block header verification is performed, including:

[0346] If the first block digest is the same as the second block digest, it is determined that the block header verification is successful.

[0347] Optionally, if the block header verification succeeds, and the previous block proof corresponding to the previous block height of the added block is obtained from the block validity proof queue, a block validity proof of the added block is generated, including:

[0348] If the block header verification succeeds, and the previous block certificate corresponding to the previous block height of the added block is obtained from the block valid certificate queue, then the first signature of the first blockchain network recording the added block and the first key of the first blockchain network are obtained;

[0349] Decrypting the first signature using the first key to obtain a decryption result;

[0350] Calculate the digest of the added block and compare the digest with the decryption result;

[0351] If the digest is consistent with the decryption result, a block validity certificate for the added block is generated.

[0352] Optionally, the block identifier of the target block is included in the cross-chain transaction to be processed;

[0353] The first generating unit 3030 is specifically used for:

[0354] In response to the target block validity proof, based on the block identifier, determining that the transaction to be processed across the chain is located in the target block;

[0355] Based on the target block validity proof and the relationship between the transaction to be processed across the chain and the target block, a transaction validity proof is generated.

[0356] Optionally, the first generating unit 3030 is specifically configured to:

[0357] Based on the block identifier, obtain the Merkle tree root to be verified of the target block and the bypass summary value for verification of the cross-chain transaction in the target block;

[0358] Determine the recalculation of the Merkle tree root based on the transaction to be processed across the chain and the bypass summary value for verification;

[0359] If the Merkle tree root to be verified is the same as the recalculated Merkle tree root, it is determined that the transaction to be processed across the chain is located in the target block.

[0360] Optionally, the first acquiring unit 3010 is specifically configured to:

[0361] Obtaining the transactions uploaded to the first blockchain;

[0362] Get the transactions to be processed across the chain from the on-chain transactions that contain the forwarding tag.

[0363] Optionally, the first acquiring unit 3010 is specifically configured to:

[0364] Store the on-chain transactions containing the forwarding marker in the transaction buffer pool;

[0365] After the transactions in the transaction buffer pool meet the predetermined conditions, the transactions in the transaction buffer pool are taken out as transactions to be processed across the chain.

[0366] Optionally, the on-chain transaction including the forwarding tag is generated in the first blockchain network in the following manner:

[0367] Obtain the transaction to be uploaded to the chain, and determine the first transaction type of the transaction to be uploaded to the chain;

[0368] Obtaining a transaction processing contract corresponding to the first transaction type;

[0369] If the transaction to be on-chain meets the predetermined forwarding conditions in the transaction processing contract, the transaction processing contract adds a forwarding mark to the transaction to be on-chain, records the transaction to be on-chain in the first blockchain, and generates an on-chain transaction containing the forwarding mark.

[0370] Fig.31 A schematic diagram of the structure of a cross-blockchain transaction processing device 3100 located in a second blockchain network provided in an embodiment of the present disclosure. The cross-blockchain transaction processing device 3100 includes:

[0371] The receiving unit 3110 is used to receive a transaction validity certificate from a cross-chain relay node, wherein the transaction validity certificate is generated by the cross-chain relay node for the transaction to be processed across the chain, based on the ownership relationship between the transaction to be processed across the chain and the target block, and the block validity certificate of the target block, wherein the transaction to be processed across the chain has been recorded in the first blockchain of the first blockchain network and needs to be recorded in the second blockchain, the block validity certificate is obtained from the block validity certificate queue, the block validity certificate queue stores the block validity certificate of the chained block according to the chaining order of the chained blocks on the first blockchain, and the block validity certificate is generated by the cross-chain relay node when the chained block is recorded in the first blockchain by performing block verification on the chained block and is placed in the block validity certificate queue;

[0372] A verification unit 3120, for authenticating the identity of the cross-chain relay node based on the received transaction validity proof;

[0373] The transaction recording unit 3130 is used to record the transaction to be processed across chains to the second blockchain after the identity authentication is successful.

[0374] Optionally, the transaction validity proof is a transaction validity proof encrypted by the cross-chain relay node using a first private key, and the first private key is issued by the blockchain management contract after being registered by the cross-chain relay node on the blockchain management contract stored on the second blockchain network;

[0375] The verification unit 3120 is specifically used for:

[0376] Obtain the first public key of the cross-chain relay node from the blockchain management contract, wherein the first public key and the first private key are issued in pairs by the blockchain management contract;

[0377] The transaction is decrypted with the first public key to prove validity, thereby authenticating the identity of the cross-chain relay node.

[0378] Optionally, each first blockchain network corresponds to a cross-chain relay node;

[0379] The second blockchain network registers the cross-chain relay node in the following way:

[0380] Receiving a blockchain node registration request from a first blockchain network;

[0381] The blockchain management contract issues a first public key and a first private key to the cross-chain relay node corresponding to the first blockchain network;

[0382] Based on the blockchain node registration request, a blockchain verification contract corresponding to the first blockchain network is generated, wherein the blockchain verification contract is used to authenticate the cross-chain relay node using the first public key.

[0383] Optionally, the transaction recording unit 3130 is specifically used for:

[0384] After successful identity authentication, obtain the second transaction type of the transaction to be processed across the chain;

[0385] Retrieve the transaction summary contract corresponding to the second transaction type to generate a summary transaction based on multiple transactions to be processed across the chain of the second transaction type;

[0386] The aggregated transaction is recorded on the second blockchain.

[0387] Optionally, the cross-blockchain transaction processing device 3100 further includes:

[0388] A second generating unit (not shown), configured to generate a transaction processing feedback message based on the recorded result of the transaction to be processed across the chain;

[0389] The second sending unit (not shown) is used to send the transaction processing feedback message to the first blockchain network so that the first blockchain updates the forwarding status of the transaction to be cross-chain processed, and the forwarding status indicates whether the transaction to be cross-chain processed is successfully recorded by the second blockchain.

[0390] Reference Fig.32 , Fig.32 The structural block diagram of the terminal part of the cross-blockchain transaction processing method for implementing the embodiment of the present disclosure includes: Radio Frequency (RF) circuit 3210, memory 3215, input unit 3230, display unit 3240, sensor 3250, audio circuit 3260, wireless fidelity (WiFi) module 3270, processor 3280, and power supply 3290. Those skilled in the art can understand that Fig.32 The terminal structure shown does not constitute a limitation on the mobile phone or computer, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0391] The RF circuit 3210 may be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information from the base station, it is sent to the processor 3280 for processing; in addition, the designed uplink data is sent to the base station.

[0392] The memory 3215 may be used to store software programs and modules, and the processor 3280 executes various functional applications of the terminal by running the software programs and modules stored in the memory 3215 .

[0393] The input unit 3230 may be used to receive input digital or character information and generate key signal input related to the terminal's settings and function control. Specifically, the input unit 3230 may include a touch panel 3231 and other input devices 3232 .

[0394] The display unit 3240 may be used to display input information or provided information and various menus of the terminal. The display unit 3240 may include a display panel 3241.

[0395] The audio circuit 3260 , the speaker 3261 , and the microphone 3262 may provide an audio interface.

[0396] In this embodiment, the processor 3280 included in the terminal can execute the cross-blockchain transaction processing method of the previous embodiment.

[0397] The terminals of the embodiments of the present disclosure include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. The embodiments of the present invention can be applied to various scenarios, including but not limited to blockchain, virtual digital resources, security technology, etc.

[0398] Fig.33 A block diagram of the structure of a portion of a server for implementing the cross-blockchain transaction processing method of an embodiment of the present disclosure. The server may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 3322 (e.g., one or more processors) and storage devices 3332, and one or more storage media 3330 (e.g., one or more massive storage devices) storing application programs 3342 or data 3344. Among them, the storage device 3332 and the storage medium 3330 may be short-term storage or persistent storage. The program stored in the storage medium 3330 may include one or more modules (not shown in the figure), each of which may include a series of instruction operations on the server. Furthermore, the central processing unit 3322 may be configured to communicate with the storage medium 3330 and execute a series of instruction operations in the storage medium 3330 on the server.

[0399] The server may also include one or more power supplies 3326, one or more wired or wireless network interfaces 3350, one or more input and output interfaces 3358, and / or one or more operating systems 3341, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0400] The central processor 3322 in the server can be used to execute the cross-blockchain transaction processing method of the embodiment of the present disclosure.

[0401] The embodiments of the present disclosure also provide a computer-readable storage medium, which is used to store program code, and the program code is used to execute the cross-blockchain transaction processing method of each of the aforementioned embodiments.

[0402] The present disclosure also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, so that the computer device executes and implements the above-mentioned cross-blockchain transaction processing method.

[0403] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprises" and "comprising" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0404] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0405] It should be understood that in the description of the embodiments of the present disclosure, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.

[0406] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0407] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0408] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0409] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0410] It should also be understood that the various implementations provided in the embodiments of the present disclosure can be combined arbitrarily to achieve different technical effects.

[0411] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A cross-blockchain transaction processing method, characterized in that: The cross-blockchain transaction processing method is applied to a cross-chain relay node between a first blockchain network and a second blockchain network, wherein the first blockchain network maintains a first blockchain and the second blockchain network maintains a second blockchain, and the method includes: Obtaining a transaction to be processed across the chain, wherein the transaction to be processed across the chain has been recorded in the first blockchain and needs to be recorded in the second blockchain; Obtaining a block validity proof queue, wherein the block validity proof queue stores the block validity proof of the chained block according to the chaining order of the chained block on the first blockchain, wherein the block validity proof of the chained block is generated by the cross-chain relay node performing block verification on the chained block when the chained block is recorded in the first blockchain and is placed in the block validity proof queue; Obtaining the target block validity certificate corresponding to the transaction to be processed across the chain from the block validity certificate queue, and generating a transaction validity certificate based on the target block validity certificate; The transaction validity proof is sent to the second blockchain network so that the second blockchain network records the transaction to be cross-chain processed to the second blockchain based on the transaction validity proof.

2. The cross-blockchain transaction processing method according to claim 1, characterized in that: The block validity proof queue is pre-generated in the following way: Obtaining an additional block added to the first blockchain; Verifying the added block using a block verification algorithm to generate a block validity certificate for the added block; The block validity proof is recorded in the block validity proof queue according to the block height of the added block in the first blockchain.

3. The cross-blockchain transaction processing method according to claim 2, characterized in that: The using a block verification algorithm to verify the added block and generate the block validity certificate of the added block includes: Obtaining a first block header of the added block and a second block header of a block before the added block; Performing block header verification based on the first block header and the second block header; If the block header verification succeeds, and the previous block certificate corresponding to the previous block height of the added block is obtained from the block validity certificate queue, the block validity certificate of the added block is generated.

4. The cross-blockchain transaction processing method according to claim 3 is characterized in that: The first block header includes a first block digest of the previous block, and the second block header includes a second block digest of the previous block; The performing block header verification based on the first block header and the second block header includes: If the first block digest is identical to the second block digest, it is determined that the block header verification is successful.

5. The cross-blockchain transaction processing method according to claim 3 is characterized in that: If the block header verification succeeds, and a previous block certificate corresponding to the previous block height of the added block is obtained from the block validity certificate queue, then the block validity certificate of the added block is generated, including: If the block header verification succeeds, and a previous block certificate corresponding to the previous block height of the added block is obtained from the block valid certificate queue, then a first signature of the first blockchain network recording the added block and a first key of the first blockchain network are obtained; Decrypting the first signature using the first key to obtain a decryption result; Calculating a digest of the added block, and comparing the digest with the decryption result; If the digest is consistent with the decryption result, the block validity certificate of the added block is generated.

6. The cross-blockchain transaction processing method according to claim 1, characterized in that: The block identifier of the target block included in the cross-chain transaction to be processed; The generating a transaction validity certificate based on the target block validity certificate includes: In response to the target block validity proof, based on the block identifier, determining that the transaction to be cross-chain processed is located in the target block; Based on the target block validity proof and the ownership relationship between the transaction to be processed across the chain and the target block, a transaction validity proof is generated.

7. The cross-blockchain transaction processing method according to claim 6, characterized in that: The determining, based on the block identifier, that the transaction to be cross-chain processed is located in the target block includes: Based on the block identifier, obtaining the Merkle tree root to be verified of the target block and the bypass digest value for verification of the transaction to be cross-chain processed in the target block; Determine to recalculate the Merkle tree root based on the transaction to be processed across chains and the bypass digest value for verification; If the Merkle tree root to be verified is the same as the recalculated Merkle tree root, it is determined that the transaction to be cross-chain processed is located in the target block.

8. The cross-blockchain transaction processing method according to claim 1, characterized in that: The obtaining of the transaction to be processed across the chain includes: Obtaining transactions uploaded to the first blockchain; From the on-chain transactions that include the forwarding tag, obtain the transactions to be processed across the chain.

9. The cross-blockchain transaction processing method according to claim 8, characterized in that: The obtaining, from the on-chain transaction containing the forwarding mark, the transaction to be processed across the chain, comprises: Storing the on-chain transaction including the forwarding tag in a transaction buffer pool; After the transaction in the transaction buffer pool meets a predetermined condition, the transaction in the transaction buffer pool is taken out as the transaction to be processed across the chain.

10. The cross-blockchain transaction processing method according to claim 8, characterized in that: The on-chain transaction including the forwarding tag is generated in the first blockchain network in the following manner: Obtaining a transaction to be uploaded to the chain, and determining a first transaction type of the transaction to be uploaded to the chain; Obtaining a transaction processing contract corresponding to the first transaction type; If the transaction to be on-chain meets the predetermined forwarding conditions in the transaction processing contract, the transaction processing contract adds the forwarding mark to the transaction to be on-chain, records the transaction to be on-chain in the first blockchain, and generates the on-chain transaction containing the forwarding mark.

11. A cross-blockchain transaction processing method, characterized in that: The cross-blockchain transaction processing method is applied to a second blockchain network, where the second blockchain network maintains a second blockchain, and the method includes: Receive a transaction validity certificate from a cross-chain relay node, wherein the transaction validity certificate is generated by the cross-chain relay node for the transaction to be processed across the chain, based on the ownership relationship between the transaction to be processed across the chain and the target block, and the block validity certificate of the target block, wherein the transaction to be processed across the chain has been recorded in the first blockchain of the first blockchain network and needs to be recorded in the second blockchain, the block validity certificate is obtained from a block validity certificate queue, the block validity certificate queue stores the block validity certificate of the chained block according to the chaining order of the chained blocks on the first blockchain, and the block validity certificate is generated by the cross-chain relay node when the chained block is recorded in the first blockchain by performing block verification on the chained block and is placed in the block validity certificate queue; Authenticating the identity of the cross-chain relay node based on the received transaction validity proof; After the identity authentication is successful, the transaction to be processed across the chain is recorded in the second blockchain.

12. The cross-blockchain transaction processing method according to claim 11, characterized in that: The transaction validity proof is the transaction validity proof encrypted by the cross-chain relay node using the first private key, and the first private key is registered by the cross-chain relay node on the blockchain management contract stored on the second blockchain network and issued by the blockchain management contract; The authenticating the identity of the cross-chain relay node based on the received transaction validity proof includes: Obtaining a first public key of the cross-chain relay node from the blockchain management contract, wherein the first public key and the first private key are issued in pairs by the blockchain management contract; The transaction validity certificate is decrypted using the first public key, thereby authenticating the identity of the cross-chain relay node.

13. The cross-blockchain transaction processing method according to claim 12, characterized in that: Each of the first blockchain networks corresponds to one of the cross-chain relay nodes; The second blockchain network registers the cross-chain relay node in the following manner: Receiving a blockchain node registration request from the first blockchain network; The blockchain management contract issues the first public key and the first private key to the cross-chain relay node corresponding to the first blockchain network; Based on the blockchain node registration request, a blockchain verification contract corresponding to the first blockchain network is generated, wherein the blockchain verification contract is used to authenticate the identity of the cross-chain relay node using the first public key.

14. The cross-blockchain transaction processing method according to claim 11, characterized in that: After the identity verification is successful, recording the transaction to be processed across chains to the second blockchain includes: After the identity verification is successful, obtaining a second transaction type of the transaction to be processed across the chain; Retrieve a transaction summary contract corresponding to the second transaction type to generate a summary transaction based on the plurality of the to-be-processed cross-chain transactions of the second transaction type; The aggregated transaction is recorded on the second blockchain.

15. The cross-blockchain transaction processing method according to claim 11, characterized in that: After the identity authentication is successful, after the transaction to be cross-chain processed is recorded in the second blockchain, the cross-blockchain transaction processing method further includes: Generate a transaction processing feedback message based on the recorded result of the transaction to be processed across the chain; The transaction processing feedback message is sent to the first blockchain network so that the first blockchain updates the forwarding status of the transaction to be cross-chain processed, and the forwarding status indicates whether the transaction to be cross-chain processed is successfully recorded by the second blockchain.

16. A cross-blockchain transaction processing device, characterized in that: The cross-blockchain transaction processing device is located at a cross-chain relay node between the first blockchain network and the second blockchain network, and includes: A first acquisition unit, configured to acquire a transaction to be processed across the chain, wherein the transaction to be processed across the chain has been recorded in the first blockchain and needs to be recorded in the second blockchain; A second acquisition unit is used to acquire a block validity proof queue, wherein the block validity proof queue stores the block validity proof of the chained block according to the chaining order of the chained block on the first blockchain, wherein the block validity proof of the chained block is generated by the cross-chain relay node performing block verification on the chained block when the chained block is recorded in the first blockchain and is placed in the block validity proof queue; A first generating unit is configured to obtain a target block validity certificate corresponding to the to-be-cross-chain-processed transaction from the block validity certificate queue, and generate a transaction validity certificate based on the target block validity certificate; The first sending unit is used to send the transaction validity certificate to the second blockchain network, so that the second blockchain network records the transaction to be cross-chain processed to the second blockchain based on the transaction validity certificate.

17. A cross-blockchain transaction processing device, characterized in that: The cross-blockchain transaction processing device is located in the second blockchain network and includes: A receiving unit, configured to receive a transaction validity certificate from a cross-chain relay node, wherein the transaction validity certificate is generated by the cross-chain relay node for the transaction to be processed across the chain, based on the ownership relationship between the transaction to be processed across the chain and the target block, and the block validity certificate of the target block, wherein the transaction to be processed across the chain has been recorded in a first blockchain of a first blockchain network, and needs to be recorded in the second blockchain, the block validity certificate is obtained from a block validity certificate queue, the block validity certificate queue stores the block validity certificate of the chained block in the order of chaining the chained blocks on the first blockchain, and the block validity certificate is generated by the cross-chain relay node when the chained block is recorded in the first blockchain by performing block verification on the chained block and is placed in the block validity certificate queue; A verification unit, configured to authenticate the identity of the cross-chain relay node based on the received transaction validity certificate; A transaction recording unit is used to record the transaction to be processed across the chain into the second blockchain after the identity authentication is successful.

18. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the cross-blockchain transaction processing method according to any one of claims 1 to 15 is implemented.

19. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the cross-blockchain transaction processing method according to any one of claims 1 to 15 is implemented.

20. A computer program product, comprising a computer program, wherein the computer program is read and executed by a processor of a computer device, so that the computer device executes the cross-blockchain transaction processing method according to any one of claims 1 to 15.

Images