Transaction chaining method and related apparatus, and medium

Abstract

Provided in the present application are a transaction chaining method and a related apparatus, and a medium. The transaction chaining method comprises: receiving a local transaction to be processed and first verification information corresponding to the local transaction to be processed, wherein the local transaction to be processed is located in a local block to be processed, and the local block to be processed is recorded on a local blockchain; receiving block headers of a plurality of local blocks, which are recorded on the local blockchain, wherein the plurality of local blocks comprise the local block to be processed; performing first verification on the basis of the block headers of the plurality of local blocks; performing second verification on the basis of the local transaction to be processed, the first verification information and the block header of the local block to be processed; and after both the first verification and the second verification are passed, generating, on the basis of the local transaction to be processed, a global transaction to be processed, and recording same on a global blockchain. By means of the embodiments of the present application, the chaining security of a global transaction in a blockchain hierarchical consensus system is improved. The embodiments of the present application may be applied to various scenarios, such as blockchains, structured information processing, security techniques, etc.

Description

A transaction chain method, related device and medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on May 18, 2023, with application number 202310566205.5 and application name “Transaction Chaining Method, Related Devices and Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of blockchain, and in particular to a method for uploading transactions to a blockchain, related devices, and media. Background Art

[0003] The blockchain layered consensus network consists of a local consensus network and a global consensus network. Local transactions used to generate global transactions in the local consensus network are forwarded to the global consensus network through a third-party relay, and the global consensus network then generates global transactions.

[0004] However, in the process of transmitting local transactions to the global consensus network, once the third-party relay cheats or is attacked by the network during the transmission process, the security of cross-chain transaction forwarding is difficult to guarantee, and the accuracy of global transaction on-chain is low.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide a transaction on-chain method, related devices and media, which can improve the security of cross-chain transaction forwarding in the blockchain layered consensus system and improve the accuracy of global transaction on-chain.

[0007] According to one aspect of the present application, a transaction on-chain method is provided, the method being executed by a global consensus node, comprising:

[0008] Receiving a pending local transaction and first verification information corresponding to the pending local transaction, wherein the pending local transaction is located in a pending local block, and the pending local block is recorded on a local blockchain;

[0009] Receiving block headers corresponding to a plurality of local blocks recorded on the local blockchain, wherein the plurality of local blocks include the local block to be processed;

[0010] Performing a first verification based on the block headers corresponding to each of the plurality of local blocks;

[0011] Performing a second verification based on the pending local transaction, the first verification information, and the block header of the pending local block;

[0012] When both the first verification and the second verification are passed, a pending global transaction is generated based on the pending local transaction, and the pending global transaction is recorded on the global blockchain.

[0013] According to one aspect of the present application, a transaction on-chain device is provided, which is deployed on a global consensus node and includes:

[0014] A first receiving unit is configured to receive a pending local transaction and first verification information corresponding to the pending local transaction, wherein the pending local transaction is located in a pending local block, and the pending local block is recorded on a local blockchain;

[0015] A second receiving unit is configured to receive block headers corresponding to a plurality of local blocks recorded on the local blockchain, wherein the plurality of local blocks include the local block to be processed;

[0016] A first verification unit, configured to perform a first verification based on block headers corresponding to each of the plurality of local blocks;

[0017] A second verification unit, configured to perform a second verification based on the local transaction to be processed, the first verification information, and a block header of the local block to be processed;

[0018] An authorization unit is configured to generate a pending global transaction based on the pending local transaction and record the pending global transaction on a global blockchain when both the first verification and the second verification are passed.

[0019] According to one aspect of the present application, an electronic device is provided, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the transaction chaining method as described above when executing the computer program.

[0020] According to one aspect of the present application, 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 transaction chaining method as described above is implemented.

[0021] According to one aspect of the present application, 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 executes the transaction chaining method as described above.

[0022] In an embodiment of the present application, in addition to receiving the pending local transactions used to generate the pending global transactions, the global consensus nodes in the global consensus network also receive the first verification information corresponding to the pending local transactions and the block headers of each local block recorded in the local blockchain. Based on the block headers of each local block, the security of the pending local block where the pending local transaction is located is verified, i.e., the first verification. Based on the pending local transaction, the first verification information, and the block header of the pending local block, the security of the pending local transaction itself is verified, i.e., the second verification. After both verifications are passed, the pending global transaction is generated based on the pending local transaction, and the pending global transaction is recorded on the global blockchain. Through two security verifications, the insecurity caused by third-party relay cheating or network transmission reasons is greatly reduced, and the security of cross-chain transaction forwarding and the accuracy of global transaction chain upload are improved. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0024] FIG1 is a schematic diagram of the system architecture of a blockchain layered consensus network to which an embodiment of the present application is applied;

[0025] FIG2 is a schematic diagram of an embodiment of the present application of a transaction on-chain method in an electronic invoice aggregation scenario;

[0026] FIG3 is a flow chart of a transaction on-chain method according to an embodiment of the present application;

[0027] FIG4 is a schematic diagram showing an implementation process of the transaction on-chain method in FIG3 ;

[0028] FIG5 is a flowchart of step 310 in FIG3 using the first relay node to implement receiving a local transaction to be processed;

[0029] FIG6 is a schematic diagram showing a situation in which a new local block is added to the local blockchain in FIG4 ;

[0030] FIG7 is a flowchart of a local consensus node adding a first mark before step 511 of FIG5 ;

[0031] FIG8 is a flowchart of step 310 in FIG3 using the first relay node to implement receiving the first verification information;

[0032] FIG9A shows a schematic diagram of an implementation process of generating a first tree in an embodiment of the present application;

[0033] FIG9B is a schematic diagram showing a first bypass feature of a first path of a first tree in an embodiment of the present application;

[0034] 10 is a flowchart of a first relay node using a queue to queue and send an embodiment of the present application;

[0035] FIG11 is a schematic diagram showing an implementation process of queuing and sending using queues belonging to different transaction types in an embodiment of the present application;

[0036] FIG12 is a flowchart showing a specific implementation of step 1013 in FIG10 ;

[0037] 13 is a flowchart of a first relay node using transaction priority and timestamp to queue and send an embodiment of the present application;

[0038] FIG14 shows a schematic diagram of the specific implementation process of queuing and sending in FIG13;

[0039] FIG15 is a flowchart showing a specific implementation of step 1312 in FIG13 ;

[0040] FIG16 is a flowchart of authenticating the first relay node in combination with the blockchain management contract in FIG3 ;

[0041] FIG17 is a flow chart of implementing receiving a block header using a second relay node in step 320 of FIG3 ;

[0042] FIG18 is a flow chart of authenticating the second relay node in conjunction with the blockchain management contract in FIG3 ;

[0043] FIG19 is a schematic diagram showing the implementation process of the first verification based on the block header of a local block;

[0044] FIG20 is a flowchart showing a specific implementation of step 340 in FIG3 ;

[0045] FIG21 is a flowchart showing a specific implementation of step 350 in FIG3 ;

[0046] FIG22 is a flowchart of FIG3 in combination with the blockchain management contract to distinguish different global blockchains;

[0047] FIG23 is a flowchart of implementing the second verification in combination with the first verification contract and the second verification contract in combination with FIG3;

[0048] FIG24 is a multi-terminal interaction diagram of a detailed embodiment of the present application;

[0049] FIG25 is a module diagram of a transaction on-chain device according to one embodiment of the present application;

[0050] FIG26 is a terminal structure diagram of the transaction on-chain method according to FIG3 of an embodiment of the present application;

[0051] Figure 27 is a server structure diagram of the transaction chain method shown in Figure 3 according to the embodiment of the present application. DETAILED DESCRIPTION

[0052] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0053] Before further explaining the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations:

[0054] Artificial intelligence (AI) is the theory, methods, techniques, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, to perceive the environment, acquire knowledge, and use that knowledge to achieve desired outcomes. In other words, AI is a comprehensive field within computer science that seeks to understand the essence of intelligence and create new intelligent machines that can respond in a manner similar to human intelligence. AI also studies the design principles and implementation methods of various intelligent machines, enabling them to possess the capabilities of perception, reasoning, and decision-making. AI technology is an interdisciplinary discipline encompassing a wide range of fields, encompassing both hardware and software technologies. Foundational AI technologies generally include sensors, specialized AI chips, cloud computing, distributed storage, big data processing, operating / interaction systems, and mechatronics. AI software technologies primarily encompass computer vision, speech processing, natural language processing, and machine learning / deep learning. With the research and advancement of artificial intelligence technology, artificial intelligence technology has been studied and applied in many fields, such as common smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, unmanned driving, autonomous driving, drones, robots, smart medical care, smart customer service, etc. It is believed that with the development of technology, artificial intelligence technology will be applied in more fields and play an increasingly important role.

[0055] Blockchain: Blockchain is a new application model for computer technologies such as distributed data storage, peer-to-peer transmission (P2P networks), consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a series of data blocks linked using cryptographic methods. Each block contains information about a batch of transactions, used to verify the validity of the information (to prevent counterfeiting) and link it to the previous block.

[0056] P2P network: A peer-to-peer network. Based on a specific network protocol, P2P networks do not require a central node to maintain network status. Instead, each node maintains the overall network status or the connection status of its neighboring nodes through broadcast interactions with neighboring nodes.

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

[0058] The blockchain layered consensus system consists of a local consensus network and a global consensus network. Local transactions used to generate global transactions in the local consensus network are forwarded to the global consensus network through a third-party relay, and the global consensus network then generates global transactions.

[0059] Currently, the relevant technologies lack the technology to ensure the security of local transactions during transmission to the global consensus network. If a third-party relay cheats or the transmission process is attacked by a network attack, the security of cross-chain transaction forwarding will be difficult to guarantee, and the accuracy of global transaction on-chain will be low.

[0060] System architecture and scenario description of the application examples

[0061] Referring to the blockchain layered consensus network shown in Figure 1, a blockchain layered consensus network refers to a blockchain network used for layered consensus on transactions. This network includes a local consensus network, a global consensus network, a first relay node, and a second relay node. The local consensus network is a network that reaches consensus on local transactions and uploads them to the blockchain, and includes multiple local consensus nodes. Local transactions are transactions that affect only a local scope. For example, transactions related to electronic invoice reimbursement for a group's branch companies are local transactions. The global consensus network is a network that reaches consensus on global transactions derived from local transactions and uploads them to the blockchain, and includes multiple global consensus nodes. Global transactions are transactions that affect the global scope. For example, transactions that aggregate electronic invoice reimbursements for a group's branches are global transactions. The first and second relay nodes serve as interface nodes between the local consensus nodes and the global consensus nodes, forwarding local transactions generated by the local consensus network to the global consensus network, which then aggregates the local transactions into global transactions and uploads them to the blockchain.

[0062] It should be noted that both local consensus nodes and global consensus nodes are consensus nodes, also known as blockchain nodes. A consensus node or blockchain node can be an electronic device within a blockchain network, such as a server within the blockchain network, or an electronic device connected to the blockchain network, such as a user terminal connected to the blockchain network. The specific form of a consensus node or blockchain node is not limited here. The first relay node and the second relay node are both interface nodes. The first relay node and the second relay node can be independent devices, such as separate computers or servers. Alternatively, they can be part of an independent device, such as a virtual machine partitioned from a server. The specific form of the first relay node and the second relay node is not limited here.

[0063] The embodiments of the present application can be applied in a variety of scenarios, such as the electronic invoice aggregation scenario shown in Figure 2.

[0064] See Figure 2. Figure 2 differs from Figure 1 in that it also shows the local blockchain maintained by the local consensus network and the global blockchain maintained by the global consensus network. Both the local blockchain and the global blockchain are the same blockchains described above. The specific process for recording local transactions on the local blockchain is as follows:

[0065] Generally, an object terminal (e.g., a user terminal) can generate a local transaction based on the operation behavior of an object (e.g., a user), and send the local transaction and the digital signature of the object terminal to a neighboring local consensus node on the local consensus network, so that the local consensus node can verify the authenticity of the local transaction. During verification, the local consensus node verifies the digital signature using the public key of the object terminal to obtain the first digest value of the local transaction, and calculates the digest of the local transaction according to the digest algorithm to obtain the second digest value of the local transaction. The first digest value and the second digest value are compared. If the first digest value and the second digest value are the same, the verification is successful, and the local transaction is a real transaction generated by the object terminal.

[0066] After verification, the local transaction and other local transactions sent by the target terminal are accumulated. When the accumulation reaches a certain level (for example, the number of accumulated transactions reaches a certain threshold, or the accumulation time reaches a certain threshold), these local transactions are packaged into a local block and sent to other first consensus nodes in the local consensus network for consensus. After consensus is successful, each local consensus node records the local block on the local blockchain maintained by the local consensus node.

[0067] Continuing with Figure 2, the local blockchain consists of three local blocks. Local blocks 1-3 record three local transactions: "Company A's May invoice reimbursement A001, amount 100," "Company A's May invoice reimbursement A002, amount 300," and "Company A's May invoice reimbursement A003, amount 100." These three local transactions on the local blockchain are forwarded to the global consensus node of the global consensus network via the first or second relay node. The global consensus node then generates a global transaction based on these three local transactions, for example, "Company A's May invoice reimbursement total amount 500." This global transaction is then converted into a global block and recorded on the global blockchain. The specific process for recording global transactions on the global blockchain is similar to the specific process for recording local transactions on the local blockchain described above and will not be repeated here.

[0068] It can be seen from this that once a third-party relay cheats (for example, the first relay node or the second relay node cheats), or the transmission process (for example, the process of transmitting local transactions on the local blockchain to the global blockchain) is attacked by the network, the security of cross-chain transaction forwarding is difficult to guarantee, and the accuracy of global transactions on the chain is low.

[0069] General description of the embodiments of this application

[0070] According to one embodiment of the present application, a transaction on-chain method is provided.

[0071] This transaction on-chain method is generally used in business scenarios with high transaction forwarding security requirements, such as the electronic invoice aggregation scenario shown in Figure 2. Transactions recorded on a local blockchain are called local transactions, and local transactions used for aggregation are called pending local transactions. Transactions aggregated based on multiple pending local transactions are called global transactions. The embodiment of the present application provides a solution for double security verification before global transactions are on-chain, which can improve the security of global transactions on-chain. This transaction on-chain method is executed by the global consensus node in the blockchain layered consensus network.

[0072] As shown in FIG3 , a transaction on-chain method according to one embodiment of the present application may include:

[0073] Step 310: Receive a pending local transaction and first verification information corresponding to the pending local transaction, where the pending local transaction is located in a pending local block, which is recorded on the local blockchain.

[0074] Step 320: Receive block headers corresponding to multiple local blocks recorded on the local blockchain, wherein the multiple local blocks include the local block to be processed;

[0075] Step 330: Perform a first verification based on the block headers corresponding to the multiple local blocks.

[0076] Step 340: Perform a second verification based on the pending local transaction, the first verification information, and the block header of the pending local block.

[0077] Step 350: After both the first and second verifications are passed, a pending global transaction is generated based on the pending local transaction, and the pending global transaction is recorded on the global blockchain.

[0078] Steps 310 - 350 are described in detail below.

[0079] In step 310, local transactions refer to transactions recorded on the local blockchain, and pending local transactions refer to local transactions used for aggregation. The local blockchain consists of multiple local blocks. Local transactions are located in local blocks, and the local block containing the pending local transaction is called the pending local block. The first verification information is used to verify that the local consensus node has actually uploaded the local transaction to the blockchain.

[0080] For example, referring to FIG4 , four local blocks are stored on the local blockchain, including local block 1, local block 2, local block 3, and local block 4. Local transactions on the local blocks include local transaction S1 (for example, local transaction S1 is “Company A’s invoice reimbursement A001 in May, amount 100”), local transaction S2 (for example, local transaction S2 is “Company A’s invoice reimbursement A002 in May, amount 300”), local transaction S3 (for example, local transaction S3 is “Company A’s office supplies order A1001 in May, amount 1000”), and local transaction S4 (for example, local transaction S4 is “Company A’s invoice reimbursement A003 in May, amount 100”). Each local block can be a pending local block or a non-pending local block. If a local block stores a local transaction for aggregation, the local block is a pending local block. The local transactions used for aggregation include local transaction S1, local transaction S2, and local transaction S4. Therefore, local blocks 1, local block 2, and local block 4 are pending local blocks, while local block 3 is a non-pending local block. Each local block includes a block header and a block body, which specifically includes a local transaction and first verification information. Local block 1 includes a block header Q1, a local transaction S1, and first verification information M1. Local block 2 includes a block header Q2, a local transaction S2, and first verification information M2. Local block 3 includes a block header Q3, a local transaction S3, and first verification information M3. Local block 4 includes a block header Q4, a local transaction S4, and first verification information M4.

[0081] In some embodiments, the setting of the receiving period of the pending local transaction and the first verification information includes but is not limited to the following situations:

[0082] (1) After discovering that a new local block to be processed is added to the local blockchain maintained by the local consensus node, receiving the local transaction to be processed and the first verification information.

[0083] (2) According to the first receiving cycle pre-set by the global consensus node, when it is found that a new local block to be processed is added to the local blockchain maintained by the local consensus node and the first receiving cycle has passed, the local transaction to be processed and the first verification information are received.

[0084] In some embodiments, the method for receiving the to-be-processed local transaction and the first verification information includes but is not limited to the following methods:

[0085] (1) The global consensus node passively receives the pending local transaction and the first verification information, specifically including: after a pending local block is added to the local blockchain maintained by the local consensus node, the local consensus node automatically sends the local transaction and the first verification information to the global consensus node.

[0086] (2) The global consensus node actively receives the pending local transactions and the first verification information, specifically including: the global consensus node sends a summary command to the local consensus node, and the local consensus node responds to the summary command and adds a pending local block to the local blockchain, and then sends the pending local transactions and the first verification information in the pending local block to the global consensus node.

[0087] For example, referring to Figure 4 , the pending local blocks on the local blockchain are local block 1, local block 2, and local block 4. Therefore, the pending local transactions received by the global consensus network include local transaction S1, local transaction S2, and local transaction S4. Correspondingly, the first verification information received by the global consensus network includes first verification information M1, first verification information M2, and first verification information M4.

[0088] In step 320, the block header, similar to the local transaction and first verification information described above, is stored in the local block. Note that step 310 receives the pending local transaction and the first verification information corresponding to the pending local transaction, while step 320 receives the block header corresponding to the pending local transaction as well as the block header corresponding to non-pending local transactions.

[0089] In some embodiments, the block header receiving period is set including but not limited to the following situations:

[0090] (1) Immediately receive the block header after discovering that the local consensus node sends the pending local transaction and the first verification information to the global consensus network.

[0091] (2) According to the second receiving cycle pre-set by the global consensus node, when it is found that the local consensus node sends the pending local transaction and the first verification information to the global consensus network and the second receiving cycle has passed, the block header is received.

[0092] In some embodiments, the block header is received in the following ways, including but not limited to:

[0093] (1) The global consensus node passively receives the block header, specifically including: after the local consensus node automatically sends the local transaction and the first verification information to the global consensus node, the local consensus node automatically sends the block header to the global consensus node.

[0094] (2) The global consensus node actively receives the block header, specifically including: the global consensus node sends a summary command to the local consensus node, and the local consensus node responds to the summary command by sending the pending local transactions, the first verification information and the block header in the pending local block to the global consensus node.

[0095] For example, referring to Figure 4 , the local blocks to be processed on the local blockchain include local block 1, local block 2, local block 3, and local block 4, so the block headers received by the global consensus network include block header Q1, block header Q2, block header Q3, and block header Q4.

[0096] In step 330, a first verification is performed based on the block headers corresponding to each of the multiple local blocks. This first verification involves verifying the security of the pending local block containing the pending local transaction. Generally, there is a connection between multiple block headers. This first verification verifies that the connection between the multiple block headers is accurate and has not been tampered with. The pending local block containing the pending local transaction is also included in these multiple block headers, thereby achieving security verification of the pending local block containing the pending local transaction.

[0097] For example, continuing to refer to FIG4 , a first verification is performed based on block header Q1, block header Q2, block header Q3, and block header Q4. After the first verification passes, it indicates that local block 1, local block 2, and local block 4 in the local block to be processed are safe.

[0098] In step 340, a second verification is performed based on the pending local transaction, the first verification information, and the block header of the pending local block. This second verification verifies the security of the pending local transaction itself. The specific process of this second verification is described in detail below.

[0099] For example, continuing to refer to Figure 4, a second verification is performed based on the first verification information M1, the first verification information M2, the first verification information M4, the block header Q1, the block header Q2, and the block header Q4. After the second verification passes, it indicates that the local transaction S1, the local transaction S2, and the local transaction S4 in the pending local transactions are safe.

[0100] In step 350, when both the first verification and the second verification are passed, it indicates that the pending local block where the pending local transaction is located is secure and the pending local transaction itself is also secure. At this time, it is allowed to generate a pending global transaction based on the pending local transaction and record it on the global blockchain.

[0101] For example, referring to Figure 4, before this recording is performed, the global blockchain already stores global block 1 and global block 2. Global block 1 stores block header R1 and pending global transaction Y1. Global block 2 stores block header R2 and pending global transaction Y2. Based on local transactions S1, S2, and S4 in the pending local transactions, a pending global transaction Y3 is generated (for example, the pending global transaction Y3 is "Company A's total invoice reimbursement amount for May is 500"). Based on the pending global transaction Y3, global block 3 is generated, and global block 3 stores block header R3 and pending global transaction Y3. Global block 3 is then recorded on the global blockchain (that is, the dotted box on the global blockchain). After the recording is completed, global block 1, global block 2, and global block 3 are stored on the global blockchain.

[0102] Through the above steps 310-350, the global consensus network of the embodiment of the present application not only receives the pending local transaction used to generate the pending global transaction, but also receives the first verification information corresponding to the pending local transaction and the block headers of each local block recorded in the local blockchain. Based on the block headers of each local block, the security of the pending local block where the pending local transaction is located is verified. Based on the pending local transaction, the first verification information and the block header of the pending local block, the security of the pending local transaction itself is verified. After both verifications are passed, the insecurity caused by third-party relay cheating or network transmission reasons is greatly reduced, and the security of cross-chain transaction forwarding and the accuracy of global transaction on-chain are improved.

[0103] The above is a general description of steps 310-350. Steps 310-350 are described in detail below.

[0104] Detailed description of step 310

[0105] Step 310: Receive the pending local transaction and the first verification information corresponding to the pending local transaction. As shown in Figure 4, the global consensus node receives the pending local transaction and the first verification information from the local consensus node. However, in practice, cross-chain information transmission on a blockchain network is generally forwarded by a third party. In this embodiment of the present application, a first relay node is used to implement information transmission between the local consensus network and the global consensus network.

[0106] In the specific implementation of this embodiment, referring to FIG5 , step 310 includes:

[0107] Step 520: Receive the local transaction to be processed and the first verification information from the first relay node.

[0108] Next, step 520 is divided into two situations. The first situation is that the first relay node receives the local transaction to be processed, and the second situation is that the first relay node receives the first verification information.

[0109] In the first case, the local transaction to be processed is obtained by the first relay node in the following manner:

[0110] Step 511: Identify the local block added to the local blockchain;

[0111] Step 512: Check the local transaction in the added local block. If the local transaction has a first tag, obtain the local transaction as a pending local transaction. The first tag indicates that the local transaction is used to generate a pending global transaction.

[0112] Steps 511-512 are described in detail below.

[0113] In step 511, a local block is added to the local blockchain, which can be identified. However, it is not yet known whether the local transaction stored in this local block is a pending local transaction or a non-pending local transaction. The first relay node identifies whether there is an added local block in the local blockchain. If an added local block is identified, in step 512, the local transaction in the local block is checked for a first tag. If the first tag is found, it is considered that a local transaction with the first tag has been found, and the local transaction with the first tag is extracted from the added local block.

[0114] As shown in Figure 6, compared to the local blockchain shown in Figure 4, the local blockchain shown in Figure 6 has additional local blocks 5 and 6. Note that although the local transactions in local blocks 1-4 are not explicitly indicated to have the first tag, other methods can be used to identify whether there are local transactions used to generate pending global transactions, not limited to the method of identifying the first tag. In this embodiment, local transaction S5 in local block 5 has the first tag, indicating that local transaction S5 is used to generate pending global transactions. However, local transaction S6 in local block 6 does not have the first tag, indicating that local transaction S6 in local block 6 does not need to be used to generate pending global transactions.

[0115] For example, consider local transaction S5: "Company A's June Invoice Reimbursement 004, Amount 200, [First Tag]," and local transaction S6: "Company A's June Office Supplies Order 1002, Amount 400." Since local transaction S5 has the first tag, the first relay node retrieves local transaction S5 from local block 5 as the pending local transaction and obtains the first verification information M5. However, local transaction S6 lacks the first tag, so the first relay node does not need to retrieve local transaction S6 or its first verification information M6.

[0116] The advantage of this embodiment is that the local transactions recorded on the local blockchain are numerous and complex, and not all local transactions are used for aggregation. The first relay node can quickly screen out local transactions for aggregation by checking the first mark and forward them to the global consensus network. This not only ensures the business isolation between the local consensus network and the global consensus network, but also allows the global consensus network to focus more on processing global transactions.

[0117] In some embodiments, the first marker in step 512 is added by the local consensus network recording the local blockchain in the following manner:

[0118] (1) Obtain a local transaction, determine the type of the local transaction, search a type comparison table according to the type of the local transaction, and if it is determined that the type of the local transaction meets the specified transaction type, add a first tag to the local transaction.

[0119] (2) Obtain the local transaction, compare the local transaction with the transaction type specified in the business contract, and if it is determined that the local transaction belongs to the specified transaction type, add a first tag to the local transaction.

[0120] Compared with method (1), method (2) does not need to look up the comparison table, but instead uses the business contracts required in the transaction chain process to achieve rapid comparison, greatly improving processing efficiency.

[0121] In the specific implementation of method (2), referring to FIG7 , the first mark is added by the local consensus network recording the local blockchain in the following manner:

[0122] Step 711: Get local transactions.

[0123] Step 712: Run the local consensus business contract to identify the transaction type specified in the local consensus business contract;

[0124] Step 713: If the local transaction belongs to the specified transaction type, add a first marker to the local transaction.

[0125] Steps 711-713 are described in detail below.

[0126] In step 711, a local transaction refers to a transaction that needs to be executed and recorded on a local blockchain, such as an invoice reimbursement transaction of a certain enterprise.

[0127] In some embodiments, methods for obtaining local transactions include but are not limited to the following methods:

[0128] (1) The local consensus node receives the pending transactions generated by the target terminal and treats the received pending transactions as local transactions.

[0129] (2) The local consensus node receives the transactions to be put on the chain forwarded by the relay node, and treats the local transactions to be put on the chain forwarded by the relay node as local transactions.

[0130] In step 712, the local consensus business contract is a smart contract as described above. A local consensus business contract refers to a contract established in advance by the local consensus network to execute various local consensus network-related services for local transactions. In this embodiment, the transaction type specified in the local consensus business contract is compared with the local transaction to determine the transaction type of the local transaction. For example, in this embodiment, the local consensus business contract is specifically an invoice reimbursement business contract, and the specified transaction type is specifically an invoice reimbursement type.

[0131] In step 713, if the local transaction belongs to the specified transaction type, it means that the local transaction belongs to a transaction for aggregation, and a first mark needs to be added.

[0132] For example, if the local transaction is "Company A's June invoice reimbursement A004, amount 200," then after running the invoice reimbursement business contract, it is recognized that the transaction type specified in the invoice reimbursement business contract is the invoice reimbursement type, and the local transaction belongs to the invoice reimbursement type. Then, after adding the first tag to the local transaction, the resulting local transaction is "Company A's June invoice reimbursement A004, amount 200, [first tag]."

[0133] The advantage of this embodiment is that, since recording local transactions to a local blockchain generally requires running the corresponding local consensus business contract, this embodiment, based on running the business contract, determines whether the local transaction belongs to the transaction type specified in the business contract, thereby quickly distinguishing whether the local transaction is for aggregation by adding a first mark. This not only improves processing efficiency but also saves computing resources.

[0134] The above is an introduction to the first scenario, and the second scenario will be described in detail below.

[0135] In the second scenario, referring to FIG8 , the first verification information is obtained by the first relay node in the following manner:

[0136] Step 811: Generate a first tree, the first tree including multiple layers of features;

[0137] Step 812: Obtain a first bypass feature of the first path as first verification information.

[0138] Steps 811-812 are described in detail below.

[0139] In step 811, the bottom layer of features of the first tree is the summary value of multiple local transactions in the local block to be processed, and the multiple local transactions include the local transaction to be processed. The order of the bottom layer of features of the first tree can be the order in which the local consensus node receives the local transactions. For example, the local consensus node first receives local transaction 1 "Invoice reimbursement B001 of enterprise B in July, amount 200", and then receives local transaction 2 "Invoice reimbursement C001 of enterprise C in July, amount 400", then local transaction 1 is used as the first node of the bottom layer node, and local transaction 2 is used as the second node of the bottom layer node. The summary algorithm used for the summary value can be one of the following:

[0140] (1) The local consensus node pre-specifies a fixed digest algorithm that is the same for each entity to which the local transaction belongs. For example, the same digest algorithm is used for the electronic invoice reimbursement transaction of enterprise B and the electronic invoice reimbursement transaction of enterprise C;

[0141] (2) The local consensus node pre-assigns different digest algorithms to the entity to which each local transaction belongs. For example, different digest algorithms are pre-assigned to Enterprise B and Enterprise C. When a local transaction is determined to belong to Enterprise B, the digest algorithm pre-assigned to Enterprise B is used; when a local transaction is determined to belong to Enterprise C, the digest algorithm pre-assigned to Enterprise C is used. This embodiment increases the difficulty of deciphering local transactions from the digest value by using different digest algorithms for different entities, thereby improving the security of local transactions on the chain.

[0142] It should be noted that no matter which of the above digest algorithms is used, it is necessary to ensure that the digest algorithm used by the global consensus node when verifying based on the digest value of the local transaction to be processed and the first bypass feature is consistent with the above digest algorithm.

[0143] In this embodiment, two adjacent features in each layer of the first tree are connected to generate a feature in a higher layer until a first root feature of the first tree is generated, and the first root feature is the first block summary value.

[0144] The first tree in the embodiment of the present application is typically a binary tree, but may also be a multi-branch tree. The first tree has all the characteristics of a tree structure, and the tree structure often includes multiple nodes (the first tree characteristics shown in FIG9A ), wherein the multiple nodes include at least one leaf node and one root node, and typically also include multiple intermediate nodes between the leaf nodes and the root node.

[0145] The specific generation process of the first tree is as follows:

[0146] Referring to the first tree shown in FIG9A , the feature data of each first tree feature is used as a feature of the first tree. Therefore, the first tree contains multiple layers of features, wherein each bottom-level feature of the first tree corresponds to a transaction recorded on a single local blockchain, and each bottom-level feature is the feature of the recorded transaction (as shown in FIG9A , the feature of the transaction is a summary value). Two adjacent features of each layer of the first tree are connected to generate a feature of a higher layer, that is, each feature in the higher layer is obtained by calculating the two adjacent features of the lower layer (as shown in FIG9A , the summary value in the feature of the higher layer can be obtained by performing a summary calculation on the summary values ​​of the two adjacent features of the lower layer). This process is repeated until the root feature of the first tree is generated, and the complete first tree is obtained. As shown in Figure 9A, the first tree feature 1 and the second tree feature 2 of the bottom layer are concatenated and then used to generate the first tree feature 7 of the second-to-last layer through a digest algorithm; the first tree feature 3 and the second tree feature 4 of the bottom layer are concatenated and then used to generate the first tree feature 8 of the second-to-last layer through a digest algorithm; the first tree feature 5 and the second tree feature of the bottom layer are concatenated and then used to generate the first tree feature 9 of the second-to-last layer through a digest algorithm; the first tree feature 7 and the second tree feature 8 of the second-to-last layer are concatenated and then used to generate the first tree feature 11 of the third-to-last layer through a digest algorithm; the first tree feature 9 and the second tree feature 10 of the second-to-last layer are concatenated and then used to generate the first tree feature 12 of the third-to-last layer through a digest algorithm; the first tree feature 11 and the second tree feature 12 of the third-to-last layer are concatenated and then used to generate the first tree feature 13, that is, the first tree root feature.

[0147] In step 812, the first path is the path between the summary value of the local transaction to be processed on the first tree and the first tree root feature, and the first bypass feature is the next layer feature to which other features on the first path except the summary value of the local transaction to be processed are connected.

[0148] As shown in FIG9B , assuming that the feature of the summary value of the local transaction to be processed corresponds to the first tree feature 4, and the first tree root feature of the first tree corresponds to the first tree feature 13, the first path is the path between the first tree feature 4 and the first tree feature 13 on the first tree, wherein the first path covers the connection paths between the first tree feature 4, the first tree feature 8, the first tree feature 11, and the first tree feature 13. Since the first tree feature 8 needs to be generated based on the first tree feature 3 and the first tree feature 4, when the feature of the first tree feature 4 is known, the feature of the first tree feature 3 also needs to be obtained. Therefore, the feature of the first tree feature 3 is determined to be a bypass feature. Similarly, since the first tree feature 11 needs to be generated based on the first tree feature 7 and the first tree feature 8, after generating the first tree feature 8 based on the first tree feature 3 and the first tree feature 4 as a bypass feature, the feature of the first tree feature 7 also needs to be obtained. Therefore, the feature of the first tree feature 7 is determined to be a bypass feature. Similarly, since the first tree feature 13 needs to be generated based on the first tree feature 11 and the first tree feature 12, after generating the first tree feature 11 based on the first tree feature 8 and the first tree feature 7 as a bypass feature, the feature of the first tree feature 12 needs to be obtained. Therefore, the feature of the first tree feature 12 is determined to be a bypass feature. Therefore, the first bypass feature of the above-mentioned first path includes the features of the first tree feature 3, the first tree feature 7, and the first tree feature 12. The first bypass feature is represented by a thick black solid line frame in Figure 9B. Other features in the first tree except the first bypass feature and the bottom layer feature corresponding to the local transaction to be processed will not be provided to the global consensus node.

[0149] The advantage of this embodiment is that when the global consensus node performs the second verification, the relevant information generated from the first tree root feature in the lowest layer corresponding to the summary value of the local transaction to be processed is provided to the global consensus node, ensuring that the global consensus node can correctly perform the second verification. At the same time, information unrelated to the generation of the first tree root feature in the lowest layer corresponding to the first tree feature in the global consensus node is avoided as much as possible from being provided to the global consensus node, thereby reducing information leakage of other transactions. At the same time, even the first bypass feature is generally only provided in the form of a summary value, etc., to reduce the leakage of the actual information of the related transaction.

[0150] The above is a detailed introduction to the second situation.

[0151] Two decomposition methods are provided below for decomposing step 310. Each decomposition method provides a detailed description of step 310 from a different perspective. The first decomposition method is described first.

[0152] In the above-mentioned process of forwarding pending local transactions and first verification information using the first relay node, whether forwarding immediately or after a predetermined forwarding period, it is equivalent to establishing a connection with the global consensus network every time a pending local transaction is encountered, which is very expensive. To reduce overhead and network resource loss, in one embodiment, the transactions can be queued first and then packaged and sent once when predetermined conditions are met.

[0153] In the specific implementation of this embodiment, the global consensus node is located on the global consensus network. Referring to FIG10 , the local transaction to be processed in step 310 is sent by the first relay node to the global consensus network in the following manner:

[0154] Step 1011: Determine the transaction type of the local transaction to be processed;

[0155] Step 1012: Based on the transaction type, place the pending local transaction into a queue corresponding to the transaction type.

[0156] Step 1013: If the queue meets the predetermined conditions, the pending local transaction in the queue is taken out and sent to the global consensus network.

[0157] Steps 1011-1013 are described in detail below.

[0158] In step 1011, the first relay node determines the transaction type of the pending local transaction. For example, if the pending local transaction is an invoice reimbursement transaction, the transaction type of the invoice reimbursement transaction itself is the invoice reimbursement type. For another example, if the pending local transaction is an enterprise order transaction, the transaction type of the enterprise order transaction itself is the order type.

[0159] In some embodiments, the transaction type of the to-be-processed local transaction is determined in the following manner, but is not limited to:

[0160] (1) Extract the first key field from the content of the local transaction to be processed, and search the first key field and transaction type comparison table based on the first key field to determine the transaction type of the local transaction to be processed. The following is an example of a first key field and transaction type comparison table:

[0161] Table 1

[0162] As shown in Table 1, for the first key fields of the partial transactions to be processed are reimbursement, invoice query and invoicing, the transaction types of the partial transactions to be processed are determined to be invoice reimbursement type, invoice query type and invoice invoicing type.

[0163] For example, the content of the partial transaction to be processed includes "Company A's June invoice reimbursement A004, amount 200", and the first key field included therein is "reimbursement", which determines that the transaction type is an invoice reimbursement type.

[0164] (2) Obtain a type identifier from the content of the local transaction to be processed, and determine the transaction type of the local transaction to be processed according to the type identifier.

[0165] For example, the content of the partial transaction to be uploaded to the chain includes "Company A's June invoice reimbursement A004, amount 200; [invoice reimbursement type]". According to the type identifier "[invoice reimbursement type]", the transaction type is determined to be the invoice reimbursement type.

[0166] In step 1012, considering that placing pending local transactions of the same transaction type into the same queue and sending them to the global consensus network together helps improve the efficiency of on-chain transactions on the global consensus network, multiple queues are set up, including queues corresponding to transaction types, so that pending local transactions of the same transaction type are placed in the same queue.

[0167] For example, Figure 11 shows two queues: subqueue P and subqueue N. Subqueue P is used to store pending local transactions of transaction type a. Subqueue N is used to store pending local transactions of transaction type b. Pending local transactions L1-L8 have been placed in corresponding queues according to their transaction types. Specifically, pending local transactions L1, L3, L5, and L7 of transaction type a are placed in queue P, while pending local transactions L2, L4, L6, and L8 of transaction type b are placed in queue N. When pending local transaction L9 needs to be placed in the queue, the transaction type of pending local transaction L9 is first determined. If the transaction type of pending local transaction L9 is transaction type a, it is placed at the end of subqueue P (in the dashed box of queue P shown in Figure 11). If the transaction type of pending local transaction L9 is transaction type b, it is placed at the end of queue N (in the dashed box of queue N shown in Figure 5).

[0168] In step 1013, the predetermined condition includes at least one of the following: the number of pending local transactions reaching a first threshold, and the time difference between the current time and the last time a pending local transaction was sent to the global consensus network. For example, in response to the number of pending local transactions in the queue reaching the first threshold, the first relay node removes the pending local transactions from the queue and sends the pending local transactions to the global consensus node. For another example, in response to the time difference between the current time in the queue and the last time a pending local transaction was sent to the global consensus network reaching a second threshold, the first relay node removes the pending local transactions from the queue and sends the pending local transactions to the global consensus node. For another example, in response to the number of pending local transactions in the queue reaching the first threshold, and in response to the time difference between the current time in the queue and the last time a pending local transaction was sent to the global consensus network reaching a second threshold, the first relay node removes the pending local transactions from the queue and sends the pending local transactions to the global consensus node.

[0169] For example, referring to Figure 11 , after placing pending local transaction L9, take the pending local transaction L9 in queue P as an example. At this time, the number of pending local transactions in queue P reaches a first threshold (for example, the first threshold is 5), and the pending local transactions in queue P are removed, that is, the pending local transactions L1, L3, L5, L7, and L9 are removed and sent to the global consensus node.

[0170] The advantage of this embodiment is that the pending local transactions of the same transaction type are stored in the same queue for batch sending. The global consensus node can use the target smart contract corresponding to the same transaction type (the target smart contract or target contract refers to the smart contract that aggregates and processes the pending local transactions of a certain transaction type, which contains the code for aggregating and processing the pending local transactions of the transaction type) to uniformly execute these pending local transactions, thereby reducing the number of calls back and forth to execute target smart contracts of different transaction types, thereby improving execution efficiency. For example, the global consensus node receives a pending local transaction sent from queue P, where all pending local transactions are executed using target smart contract T. Then, when processing these pending local transactions, the global consensus node can use target smart contract T for all of them, alleviating the problem of reducing the processing efficiency of the global consensus node due to the need to change the target smart contract multiple times.

[0171] Under the above predetermined conditions, if only the number reaching the first threshold is considered, the timeliness of transmission will be affected, resulting in some pending local transactions not being aggregated for a long time. If only the time difference reaching the second threshold is considered, although timeliness is guaranteed, the number of transactions sent each time may be too small, wasting network resources. Similarly, if both the number reaching the first threshold and the time difference reaching the second threshold are considered, there is a possibility that the time difference has met the second threshold but the number has not yet reached the first threshold, which still affects the timeliness of transmission.

[0172] In one embodiment, in order to balance the timeliness of transmission and the reduction of network resource usage, the predetermined condition can be in response to the number of pending local transactions in the queue not reaching a first threshold, and in response to the time difference between the current time in the queue and the time when the pending local transaction was last sent to the global consensus network reaching a second threshold. Referring to Figure 12, step 1013 specifically includes:

[0173] Step 1211: If the number of pending local transactions in the queue reaches a first threshold, remove the pending local transactions from the queue and send them to the global consensus network.

[0174] Step 1212: If the number of pending local transactions in the queue does not reach the first threshold, determine the time difference between the current time and the time when the pending local transaction was last sent to the global consensus network;

[0175] Step 1213: If the time difference reaches the second threshold, the pending local transaction in the queue is taken out and sent to the global consensus network.

[0176] In this embodiment, referring again to FIG. 11 , assuming the first threshold is 5, after placing pending local transaction L9 in queue P, if the number of pending local transactions in queue P reaches the first threshold, the pending local transactions in queue P can be removed and sent to the global consensus network. Before pending local transaction L9 is placed in queue P, if the time difference between the current time and the last time a pending local transaction was sent to the global consensus network reaches the second threshold, even if the number of pending local transactions in queue P does not reach the first threshold, the pending local transactions in the queue can be removed and sent to the global consensus network. In this way, by combining the number and the time difference, the number of transactions sent each time will not be too small, wasting network resources, while also taking into account timeliness, so that some pending local transactions will not be left uncollected and processed for a long time.

[0177] The above is a detailed introduction to the first decomposition method of step 310. The second decomposition method is described in detail below.

[0178] Under the second decomposition method, the urgency of each pending local transaction for aggregate processing varies. For example, if a pending local transaction is an invoice reimbursement transaction, this invoice reimbursement transaction is an urgent aggregate processing transaction and needs to be sent to the global consensus network as soon as possible. However, the first decomposition method mentioned above obviously cannot achieve the urgent forwarding of pending local transactions. Therefore, in one embodiment, it is necessary to forward the pending local transaction to the global consensus network in a timely manner based on its urgency for aggregate processing.

[0179] In the specific implementation of this embodiment, the global consensus node is located on the global consensus network. Referring to FIG13 , the local transaction to be processed is sent by the first relay node to the global consensus network in the following manner:

[0180] Step 1311: Obtain the transaction priority and timestamp of the pending local transaction;

[0181] Step 1312: Determine the processing order of pending local transactions based on the transaction priorities and timestamps.

[0182] Step 1313: Put the pending local transactions into the local transaction queue according to the processing order.

[0183] Step 1314: Take out the pending local transactions from the local transaction queue in the processing order, and send the pending local transactions to the global consensus network.

[0184] Steps 1311-1314 are described in detail below.

[0185] In step 1311, the transaction priority indicates the priority level of the pending local transaction, and the timestamp indicates the time when the pending local transaction was generated. The higher the transaction priority, the higher the priority level of the pending local transaction, and the higher the priority level of the pending local transaction, which should be forwarded to the global consensus network. The greater the time difference between the timestamp and the current time, the more likely it is that the pending local transaction has not been forwarded but is a transaction received earlier and should also be forwarded to the global consensus network with priority.

[0186] In some embodiments, the transaction priority is obtained in the following ways, including but not limited to:

[0187] (1) Determine the transaction type of the local transaction to be processed, and search the transaction type and priority comparison table based on the transaction type to determine the transaction priority. The following is an example of a transaction type and priority comparison table:

[0188] Table 2

[0189] As shown in Table 2, for invoice reimbursement transactions, the priority of pending local transactions is set to 10 because they have a higher need for urgent summary. Similarly, based on the varying degree of urgent summary requirements for each transaction type, the priority of invoice query is set to 9, and the priority of invoice issuance is set to 8.

[0190] For example, the content of the pending local transaction L9 includes "Company A's June invoice reimbursement A005, amount 700", and its transaction type is invoice reimbursement type. By looking up Table 2, it is determined that the priority is 10.

[0191] (2) Obtain a priority identifier from the content of the pending local transaction, and determine the transaction type of the pending local transaction according to the priority identifier.

[0192] For example, the content of the local transaction to be uploaded to the chain includes "Company A's June invoice reimbursement A004, amount 200; [Priority: 10]", and the priority is determined to be 10 based on the priority identifier "[Priority: 10]".

[0193] In some embodiments, the timestamp may be obtained in the following ways:

[0194] (1) Obtain a timestamp from the pending local block that records the pending local transaction.

[0195] (2) Obtain a timestamp identifier from the content of the local transaction to be processed, and determine the timestamp based on the timestamp identifier.

[0196] For example, the content of the partial transaction to be uploaded to the chain includes "Company A's June invoice reimbursement A004, amount 200; [Timestamp: XX / XX / XX]", and the timestamp is determined to be XX / XX / XX based on the timestamp identifier "[Timestamp: XX / XX / XX]".

[0197] In step 1312, the higher the transaction priority, the higher the priority of the pending local transaction in the pending local transaction queue. The larger the time difference between the timestamp and the current time, the higher the priority of the pending local transaction. For example, assuming the current time is May 7, 2023, the priority of pending local transaction L9 is 10, and the timestamp is May 4, 2023, the time difference is 3 days. Based on the priority of 10 and the time difference of 3 days, the processing order of pending local transaction L9 is determined to be 1.

[0198] In step 1313, the pending local transactions are placed into the pending local transaction queue according to the processing order. The pending local transaction queue is a container for placing pending local transactions. For example, referring to Figure 14, Figure 14 shows queue P before and after the placement of pending local transaction L9. Queue P already contains pending local transactions L1, L3, L5, and L7, with the processing order being 2, 3, 4, and 5, respectively. At this point, pending local transaction L9 has a processing order of 1. The target location for placing pending local transaction L9 into queue P is determined, namely, the dotted box in queue P shown on the left side of Figure 7. The pending local transaction L1 at the target location and the pending local transactions L3, L5, and L7 following the target location are moved backwards. Then, pending local transaction L9 is placed into queue P at the target location. The result after placement is shown in queue P on the right side of Figure 14.

[0199] In step 1314, the pending local transactions are taken out from the pending local transaction queue in the order of processing, and the pending local transactions are sent to the global consensus network.

[0200] In one embodiment, a method of removing a pending local transaction from a local transaction queue includes:

[0201] (1) When it is determined that the number of pending local transactions in the local transaction queue reaches a third threshold, the pending local transactions are taken out of the local transaction queue in the order of processing, packaged, and sent to the global consensus network;

[0202] (2) If the time difference between the current time and the time of the last package reaches the fourth threshold, the pending local transactions are taken out from the local transaction queue in the order of processing, packaged, and sent to the global consensus network.

[0203] Through steps 1311-1314, the urgent aggregation needs of pending local transactions are met according to priority and timestamp, the flexibility of transaction aggregation is improved, and thus the flexibility of global transaction chaining is improved.

[0204] The above is a general description of steps 1311-1314. The following is a detailed description of step 1312.

[0205] In one embodiment, when determining the processing order based on the transaction priority and timestamp of each pending local transaction, a total score can be calculated using the transaction priority and timestamp, and the processing order is determined based on the total score. In the specific implementation of this embodiment, referring to FIG15 , step 1312 includes:

[0206] Step 1511: Determine a first score of the pending local transaction based on the transaction priority.

[0207] Step 1512: Determine a second score of the pending local transaction based on the difference between the timestamp and the current time.

[0208] Step 1513: Determine the total score of the to-be-processed local transaction based on the first score and the second score;

[0209] Step 1514: Based on the total scores, determine the processing order of the pending local transactions.

[0210] Steps 1511-1514 are described in detail below.

[0211] In step 1511, a first score is determined based on the transaction priority, which may be determined by looking up a comparison table of transaction priorities and first scores, or by using a formula.

[0212] (1) According to the transaction priority, the transaction priority and first score comparison table is searched (the transaction priority and first score comparison table lists the corresponding relationship between the transaction priority and the first score) to obtain the first score. The following is an example of a transaction priority and first score comparison table:

[0213] Table 3

[0214] In the above example, the transaction priority of the pending local transaction L9 is 10. By looking up Table 3, the corresponding first score is 100.

[0215] The above method of searching the transaction priority and first score comparison table has the advantages of being simple and easy to implement with low processing overhead.

[0216] (2) When using the formula method, the first score can be set to be proportional to the priority of the transaction, for example:

[0217] F1=K1·GFormula 1

[0218] Wherein, F1 represents the first score, G represents the transaction priority, and K1 is a preset constant that can be set according to actual needs. For example, if K1 = 10, after substituting G = 10, the first score F1 = 100.

[0219] The advantages of the above method of determining the first score by using a formula are high accuracy, and the formula can be adjusted as needed, which is highly flexible.

[0220] In step 1512, based on the difference between the timestamp and the current time, the second score of the pending local transaction is determined. This can be done by looking up a table comparing the difference with the second score, or by using a formula.

[0221] (1) First, calculate the difference based on the timestamp and the current time. Then, use the difference to look up the difference and second score comparison table (the difference and second score comparison table lists the corresponding relationship between the difference and the second score) to obtain the second score. The following is an example of a difference and second score comparison table:

[0222] Table 4

[0223] In the above example, the difference between the timestamp of the pending local transaction L9 (May 4, 2023) and the current time (May 7, 2023) is 3 days. By looking up Table 4, the corresponding second score is 80.

[0224] The advantage of the above method of looking up the difference value and the second score comparison table is that it is simple and easy to implement and has low processing overhead.

[0225] (2) When using the formula method, the second fraction can be set to be proportional to the difference, for example: F2 = K2·H Formula 2

[0226] Wherein, F2 represents the second fraction, H represents the difference, and K2 is a preset constant that can be set according to actual needs. For example, K2 = 80 / 3, after substituting G = 3, the second fraction F2 = 80.

[0227] The advantages of the above method of determining the second score by using a formula are high accuracy, and the formula can be adjusted as needed, which is highly flexible.

[0228] In step 1513, based on the first score and the second score, the total score of the local transaction to be processed is determined, which can be done by calculating the average or weighted average of the first score and the second score.

[0229] When calculating the average of the first and second scores as the total score, for example, if the first score of pending local transaction L9 is 100 and the second score is 80, the total score is (100 + 80) / 2 = 90. The advantage of using the average to calculate the total score of pending local transactions is that it can equally reflect the impact of transaction priorities and differences on the processing order of pending local transactions in the pending local transaction queue.

[0230] When calculating the total score as the weighted average of the first and second scores, for example, if the transaction priority and difference are weighted as 0.7 and 0.3, respectively, and the first score of pending local transaction L9 is 100 and the second score is 80, the total score is 100 × 0.7 + 80 × 0.3 = 94. The advantage of using the weighted average to calculate the total score is that different weights can be set for the transaction priority and difference, which increases the flexibility of determining the processing order of pending local transactions in the pending local transaction queue.

[0231] In step 1514 , based on the total scores, the processing order of the pending local transactions is determined.

[0232] In one embodiment, the processing order is determined in the following manner:

[0233] (1) Based on the total score, search the total score and processing order comparison table (the total score and processing order comparison table lists the correspondence between the total score and the processing order) to obtain the processing order. The following is an example of a total score and processing order comparison table:

[0234] Table 5

[0235] In the above example, the total score of the pending local transaction L9 is 90. By looking up Table 5, the corresponding processing order is 1.

[0236] The advantage of the above method of searching the comparison table of total scores and processing orders is that it is simple and easy to implement, and has low processing overhead.

[0237] (2) When using the formula method, the processing order can be set to be inversely proportional to the total score, for example: D = K3·F3+K4 Formula 3

[0238] Where D represents the processing order, F3 represents the total score, and K3 and K4 are preset constants that can be set according to actual needs. For example, K3 = -2 / 90, K4 = 3. Substituting F3 = 90, D = 1.

[0239] The advantages of the above method of determining the processing order by formula are high accuracy, and the formula can be adjusted as needed, which is highly flexible.

[0240] The benefit of the embodiment of using transaction priority and difference to determine the processing order in the above steps 1511-1514 is that by effectively evaluating the degree of need for priority processing of pending local transactions, the processing order of pending local transactions with higher needs will be placed higher in the queue so that the global consensus network can give priority to the pending local transactions. This can not only alleviate the problem that some pending local transactions cannot be processed for a long time, but also improve the flexibility of processing pending local transactions.

[0241] The above is a detailed description of the second decomposition method of step 310.

[0242] In the first decomposition method or the second decomposition method in step 310 above, the first relay node forwards the pending local transactions and the first verification information in the local consensus network to the global consensus network. In other words, the global consensus network does not distinguish between first relay nodes, and any first relay node can forward transactions and information to the global consensus network. However, if there is a first relay node that maliciously forwards, the global consensus network will need to process a large amount of useless information, wasting processing resources. Therefore, in one embodiment, the identity registration of the first relay node is performed before step 310, so that the combination of identity authentication in step 310 can ensure that the pending local transactions and the first verification information are forwarded by a qualified first relay node.

[0243] In the specific implementation of this embodiment, referring to FIG16 , before step 310, the transaction on-chain further includes:

[0244] Step 1610: Receive a first authentication request from a first relay node, wherein the local transaction to be processed is received from the first relay node, and the first authentication request includes first information to be authenticated.

[0245] Step 1620: Call the blockchain management contract to perform a first authentication on the first information to be authenticated.

[0246] Step 1630: If the first authentication passes, a first token is sent to the first relay node through the blockchain management contract;

[0247] Correspondingly, step 310 includes:

[0248] Step 1640: Receive the local transaction to be processed, the first verification information, and the second token from the first relay node, where the second token is used for comparison with the first token.

[0249] In this way, after receiving the second token, step 1650 is also included: Step 1650, calling the blockchain management contract to determine whether the second token is consistent with the first token.

[0250] Steps 1610-1650 are described in detail below.

[0251] In step 1610, the first authentication request is a request from the first relay node to register its identity with the global consensus network. The first authentication information in the first authentication request includes the identity information of the first relay node. For example, the first authentication information includes the first node identifier and first key of the first relay node. The first relay node uses the first node identifier and first key as the first authentication information to generate a first authentication request and sends it to the global consensus network.

[0252] In step 1620, after receiving the first authentication request, the global consensus network extracts the first information to be authenticated from the first authentication request and then invokes the blockchain management contract to perform the first authentication on the first information to be authenticated. The blockchain management contract is a smart contract as described above. The blockchain management contract refers to a contract established in advance by the global consensus network to perform the first authentication on the first information to be authenticated. The blockchain management contract is responsible for the startup registration of all first relay nodes and the allocation of first node identifiers. For example, the first authentication information includes the first node identifier and first key of the first relay node. The blockchain management contract is invoked to perform the first authentication, and the global consensus network stores the first node identifier and first key in a local database. Once storage is complete, the first authentication is considered successful.

[0253] In step 1630, the first authentication passes, indicating that the first relay node has been successfully registered. The blockchain management contract will then assign the first relay node a first token. The first token is part of the blockchain management contract data, which serves as the data standard used by the global consensus network to authenticate the identity of the first relay node. For example, after receiving the first token, the first relay node must also include the first token when sending pending local transactions and first verification information to the global consensus network, allowing the global consensus network to authenticate the first relay node.

[0254] In step 1640, the global consensus network receives the pending local transaction, the first verification information, and the second token from the first relay node. Then, in step 1650, the blockchain management contract is invoked to compare the first token with the second token to determine whether the second token is consistent with the first token. If the second token is consistent with the first token, authentication is successful, and the global consensus network proceeds with processing the pending local transaction and the first verification information. However, if the second token is inconsistent with the first token, authentication fails, and the global consensus network filters out the pending local transaction and the first verification information and does not process them further.

[0255] The advantage of the above embodiment of verifying the first relay node in combination with the blockchain management contract is that it alleviates the problem of the global consensus network processing information forwarded by unqualified relay nodes, improves security, and saves processing resources of the global consensus network.

[0256] The above is a detailed description of step 310 .

[0257] Detailed description of step 320

[0258] Step 320: Receive block headers corresponding to multiple local blocks recorded on the local blockchain. In one embodiment, referring to FIG17 , step 320 includes:

[0259] Step 1720: Receive block headers corresponding to multiple local blocks recorded on the local blockchain from the second relay node.

[0260] In this embodiment, referring to FIG17 , the block header is sent to the global consensus network by the second relay node in the following manner:

[0261] Step 1711: Receive a first sending notification of a pending local block from a first relay node, where the first sending notification is sent after the first relay node sends the pending local transaction to the global consensus network.

[0262] Step 1712: In response to the first sending notification, obtain the block header of the sent local block to be processed and send it to the global consensus network.

[0263] Steps 1711-1712 are described in detail below.

[0264] In step 1711, after the first relay node sends the pending local transaction to the global consensus network, the first relay node generates a first send notification, which is sent to the second relay node. The second relay node receives the first send notification from the first relay node, indicating that the first relay node has sent the pending local transaction to the global consensus network, which means that the second relay node needs to forward the block header to the global consensus network.

[0265] In step 1712, the second relay node obtains a block header from the pending local block in response to the first sending notification, and the block header must include the block header of the pending local block where the pending local transaction sent by the first relay node is located.

[0266] The advantage of this embodiment is that the first relay node sends the pending local transaction and the second relay node sends the block header, and the separate transmission is used to separate data transmission and reduce the risk of tampering during the transmission process. In addition, since the block header is required for verifying the pending local transaction, the synchronization of the pending local transaction and the block header is ensured by sending the first notification, thereby ensuring verification efficiency.

[0267] In step 1720, the second relay node forwards the block header to the global consensus network. That is, the global consensus network does not distinguish between second relay nodes; any second relay node can forward block headers to the global consensus network. However, if a second relay node maliciously forwards block headers, the global consensus network will need to process a large number of useless block headers, wasting processing resources. Therefore, in one embodiment, the identity of the second relay node is registered before step 310, so that the identity authentication in step 320 can ensure that the block header is forwarded by a qualified second relay node.

[0268] In the specific implementation of this embodiment, referring to FIG18 , before step 310, the transaction on-chain method further includes:

[0269] Step 1810: Receive a second authentication request from a second relay node, wherein the block headers corresponding to the multiple local blocks are received from the second relay node, and the second authentication request includes second information to be authenticated.

[0270] Step 1820: Call the blockchain management contract to perform a second authentication on the second information to be authenticated.

[0271] Step 1830: If the second authentication passes, a third token is sent to the second relay node through the blockchain management contract;

[0272] Correspondingly, step 320 includes:

[0273] Step 1840: Receive block headers and a fourth token corresponding to multiple local blocks recorded on the local blockchain from the second relay node. The fourth token is used to compare with the third token.

[0274] Thus, after receiving the fourth token, the process further includes step 1850:

[0275] Step 1850: Call the blockchain management contract to determine whether the fourth token is consistent with the third token.

[0276] Steps 1810-1850 are described in detail below.

[0277] In step 1810, the second authentication request is a request from the second relay node to register its identity with the global consensus network. The second authentication information in the second authentication request includes the identity information of the second relay node. For example, the second authentication information includes the second node identifier and second key of the second relay node. The second relay node uses the second node identifier and second key as the second authentication information to generate a second authentication request and sends it to the global consensus network.

[0278] In step 1820, after receiving the second authentication request, the global consensus network extracts the second information to be authenticated from the second authentication request and then invokes the blockchain management contract to perform a second authentication on the second information to be authenticated. The blockchain management contract in step 1820 is similar to the blockchain management contract in step 1620 and facilitates the startup registration of the second relay node and the allocation of the second node identifier. For example, the second authentication information may include the second node identifier and second key of the second relay node. The blockchain management contract is invoked to perform the second authentication. The global consensus network then stores the second node identifier and second key of the first relay node in a local database. Once storage is complete, the second authentication is considered successful.

[0279] In step 1830, the second authentication passes, indicating that the second relay node has been successfully registered. The blockchain management contract will then assign the second relay node a third token. This third token is part of the blockchain management contract data, which serves as the data standard used by the global consensus network to authenticate the second relay node's identity. For example, after receiving the third token, the second relay node must also include the third token when sending block headers to the global consensus network, allowing the global consensus network to authenticate the second relay node.

[0280] In step 1840, the global consensus network receives the block header and the fourth token from the second relay node. Then, in step 1850, the blockchain management contract is invoked to compare the third token with the fourth token to determine whether the fourth token is consistent with the third token. If the fourth token is consistent with the third token, the second relay node's authentication is successful, and the global consensus network proceeds with further processing of the block header. However, if the fourth token is inconsistent with the third token, authentication fails, and the global consensus network filters out the block header and does not process it further.

[0281] The advantage of the above embodiment of verifying the second relay node in combination with the blockchain management contract is that it alleviates the problem of the global consensus network processing the block header forwarded by the second relay node that does not meet the conditions, while improving security and saving processing resources of the global consensus network.

[0282] The above is a detailed description of step 320 .

[0283] Detailed description of step 330

[0284] Step 330: Perform a first verification based on the block headers corresponding to the multiple local blocks.

[0285] In one embodiment, the block header of the local block includes a first block body digest value of the local block and a second block body digest value of the local block preceding the local block on the local blockchain; step 330 includes:

[0286] A first block body digest value is obtained from a block header of the local block to be processed, and a second block body digest value is obtained from a block header of a local block subsequent to the local block to be processed among the multiple local blocks; the obtained first block body digest value is compared with the obtained second block body digest value to complete the first verification.

[0287] If the first block body digest value of the partial block to be processed is the same as the second block body digest value of a subsequent partial block of the partial block to be processed among the multiple partial blocks, it is determined that the first verification is passed.

[0288] A local blockchain consists of multiple local blocks. The block header of the genesis block in the multiple local blocks stores a first block body digest value, but no second block body digest value. Among the multiple local blocks, except for the block header in the genesis block, the remaining block headers include a first block body digest value and a second block body digest value. For the same local block, the first block body digest value refers to the characteristic value of the local block, while the second block body digest value refers to the characteristic value of the previous local block (also known as the parent local block) of the local block. For two adjacent local blocks, if the first block body digest value of the previous local block is the same as the second digest value of the next local block, it means that the two local blocks are indeed related; if they are different, it means that one of the local blocks may have been tampered with and the two local blocks are not related.

[0289] For example, see Figure 19, which illustrates a schematic diagram of the implementation process for the first verification based on the block headers of a local block. Figure 19 shows four block headers, including block header Q1, block header Q2, block header Q3, and block header Q4. The first block body digest value of block header Q1 is 9ffa9bdd, and the second block body digest value is ab50f328. The first block body digest value of block header Q2 is 7b50f329, and the second block body digest value is 9ffa9bdd. The first block body digest value of block header Q3 is 5ffa9bcc, and the second block body digest value is 7b50f329. The first block body digest value of block header Q4 is 3b5tf323, and the second block body digest value is 5ffa9bcc.

[0290] Continuing with Figure 19, the first header digest value (9ffa9bdd) of header Q1 is identical to the second body digest value (9ffa9bdd) of header Q2, indicating that headers Q1 and Q2 are indeed linked. The first header digest value (7b50f329) of header Q2 is identical to the second body digest value (7b50f329) of header Q3, indicating that headers Q2 and Q3 are indeed linked. The first header digest value (5ffa9bcc) of header Q3 is identical to the second body digest value (5ffa9bcc) of header Q4, indicating that headers Q3 and Q4 are indeed linked. Finally, since headers Q1 and Q2, Q2 and Q3, and Q3 and Q4 are indeed linked, the first verification is successful.

[0291] The advantage of this embodiment is that, by leveraging the inherent correlation between adjacent local blocks, the block header is first verified on the global consensus network side. Without the need for additional verification logic, it can be determined that the multiple local blocks received have not been tampered with, thereby improving security.

[0292] The above is a detailed description of step 330 .

[0293] Detailed description of step 340

[0294] Step 340: Perform a second verification based on the local transaction to be processed, the first verification information, and the block header of the local block to be processed.

[0295] In one embodiment, referring to FIG20 , the first verification information is obtained by the first relay node in the following manner:

[0296] Step 811: Generate a first tree, the first tree including multiple layers of features;

[0297] Step 812: Obtain a first bypass feature of the first path as first verification information;

[0298] Correspondingly, step 340 includes:

[0299] Step 2010: Determine the summary value of the local transaction to be processed;

[0300] Step 2020: Determine a second root feature of the first tree based on the digest value of the local transaction to be processed and the first verification information;

[0301] Step 2030: Compare the second root feature with the first block body summary value to complete the second verification.

[0302] During the second verification, if the second root feature is consistent with the first block body digest value, the second verification passes. If the second root feature is inconsistent with the first block body digest value, the second verification fails.

[0303] Since step 811 and step 812 have been described in detail in the overall description of step 310 above, steps 2010-2030 are described in detail below.

[0304] In step 210, a digest algorithm can be used to calculate a digest of the pending local transaction to obtain a digest value of the pending local transaction. It should be noted that the digest algorithm used in both steps 210 and 220 must be consistent with the digest algorithm used to generate the first tree in step 811 to ensure the smooth execution of the second verification.

[0305] Next, in step 220, the global consensus node determines the second root feature of the first tree based on the summary value of the local transaction to be processed and the first verification information.

[0306] The process of determining the second tree root feature of the first tree includes: determining the first tree feature corresponding to the summary value of the local transaction to be processed, and then reproducing the first tree features on the first path of generating the first tree root feature layer by layer from the lowest layer of first tree features corresponding to the local transaction to be processed in the first tree based on the first bypass feature (first verification information) and the first tree feature corresponding to the summary value of the local transaction to be processed (such as the part circled by the curve in Figure 9B), thereby obtaining the second tree root feature.

[0307] As shown in FIG9B , when determining the second root feature of the first tree using the first bypass feature (first verification information) and the summary value of the local transaction to be processed, assuming that the summary value of the local transaction to be processed corresponds to the feature of the first tree feature 4, the extracted first bypass feature includes the features of the first tree feature 3, the first tree feature 7, and the first tree feature 12. At this time, the feature of the first tree feature 8 is generated based on the feature of the first tree feature 4 and the bypass feature of the first tree feature 3. The feature of the first tree feature 11 is generated based on the feature of the first tree feature 8 and the bypass feature of the first tree feature 7. The feature of the first tree feature 13 is generated based on the feature of the first tree feature 11 and the bypass feature of the first tree feature 12. In this way, the first tree features 8, 11, and 13 on the first path of generating the first tree feature 13 layer by layer from the lowest layer first tree feature 4 corresponding to the summary value of the local transaction to be processed in the first tree are reproduced. The feature of the first tree feature 13 on the reproduced first path is used as the second root feature.

[0308] After obtaining the second root signature in step 2020, the global consensus node compares the second root signature with the first block body digest value (the first root signature). In step 2030, if the second root signature is consistent with the first block body digest value, the second verification passes.

[0309] Through the above steps 2010-2030, the embodiment of the present application ensures that the global consensus node can accurately verify the local transactions to be processed, and verifies that the transactions are authentically recorded and without cheating. It also reduces the leakage of real information related to the transactions and improves security.

[0310] The above is a detailed description of step 340 .

[0311] Detailed description of step 350

[0312] Step 350: After both the first and second verifications are passed, a pending global transaction is generated based on the pending local transaction, and the pending global transaction is recorded on the global blockchain.

[0313] In one embodiment, referring to FIG. 21 , step 350 includes:

[0314] Step 2110: After both the first verification and the second verification are passed, the transaction type of the to-be-processed local transaction is obtained;

[0315] Step 2120: Call the global consensus business contract corresponding to the transaction type;

[0316] Step 2130: Execute the global consensus business contract to generate pending global transactions based on pending local transactions, and record the pending global transactions on the global blockchain.

[0317] Steps 2110-2130 are described in detail below.

[0318] In step 2110, the method for obtaining the transaction type can refer to the method for determining the transaction type in the aforementioned step 1011, which will not be repeated here to save space.

[0319] In step 2120, the global consensus business contract is a contract that aggregates pending local transactions of a certain transaction type to create a global transaction and then uploads the global transaction to the blockchain. For example, pending local transactions of the invoice reimbursement type correspond to a global consensus business contract that aggregates pending local transactions of the invoice reimbursement type. Generally speaking, a global consensus business contract must be executed by all global consensus nodes.

[0320] The global consensus business contract can be determined in the following way: according to the transaction type, find the comparison table between the transaction type and the global consensus business contract to determine the global consensus business contract.

[0321] Transaction types can be the aforementioned invoice reimbursement type, invoice query type, invoice issuance type, etc. In advance, a comparison table between transaction types and global consensus business contracts is formulated based on the contract requirements of each transaction type, for example:

[0322] Table 6

[0323] As shown in Table 6, for invoice reimbursement transactions, a unified reimbursement summary contract can be set. For invoice inquiry transactions, a unified inquiry summary contract can be set. Similarly, for invoice issuance transactions, a unified invoice issuance summary contract can be set.

[0324] After the above comparison table is prepared, you can search the above comparison table according to the transaction type to determine the global consensus business contract corresponding to the transaction type.

[0325] It is understandable that the global consensus network receives a large number of pending local transactions, and each pending local transaction may require the global consensus node to call a different global consensus business contract. If the global consensus node calls the corresponding contract for each pending global transaction, the processing efficiency will be low. In this embodiment, the first verification and the second verification are equivalent to the global consensus node running the local consensus event verification contract. The processing relationship with the target global consensus business contract can be bound in the local consensus event verification contract, which can improve processing efficiency. For example, it can be configured that when a pending local transaction with a transaction type of "invoice reimbursement" is received, after verification, the local consensus event verification contract is submitted to the "reimbursement summary contract". When a pending local transaction with a transaction type of "invoice issuance" is received, after verification, the local consensus event verification contract is submitted to the "invoice issuance summary contract".

[0326] In step 2130, the global consensus business contract is executed to generate a pending global transaction based on the pending local transaction, and the pending global transaction is recorded on the global blockchain.

[0327] For example, the three pending local transactions are "Company A's May invoice reimbursement A001, amount 100," "Company A's May invoice reimbursement A002, amount 300," and "Company A's May invoice reimbursement A003, amount 100." After passing the first and second verifications, the global consensus node detects that the transaction type of these pending local transactions is invoice reimbursement and invokes the invoice-type reimbursement contract. The global consensus node then runs the reimbursement contract, converting the three pending local transactions into a pending global transaction, "Company A's May invoice reimbursement total amount 500," and records this pending global transaction, "Company A's May invoice reimbursement total amount 500," on the blockchain. The specific process for recording pending global transactions on the global blockchain is similar to the process for recording local transactions on the local blockchain described above and will not be repeated here.

[0328] The benefit of this embodiment is that the global consensus business contract is called by the transaction type, so that the global consensus contract can be called to batch process different pending local transactions of the same transaction type, thereby improving processing efficiency and thus improving the flexibility of on-chain global transactions to be processed.

[0329] In the above embodiment, the global consensus network has a single global blockchain, which records all pending global transactions. However, in another embodiment, the local blockchains may be multiple local blockchains, and the global blockchain may be multiple global blockchains corresponding to the multiple local blockchains. In this case, the corresponding global blockchain must be selected when recording pending global transactions.

[0330] In the specific implementation of this embodiment, referring to FIG22 , before step 310, the transaction on-chain method further includes:

[0331] Step 2210: Receive a local blockchain startup request from the local consensus network;

[0332] Step 2220: In response to the local blockchain startup request, call the blockchain management contract to assign a first identifier to the local blockchain;

[0333] Step 2230: Send the first identifier to the local consensus network;

[0334] Correspondingly, step 310 includes: step 2240, receiving the local transaction to be processed, the first verification information, and the first identifier of the local blockchain;

[0335] Step 2130 includes: step 2250, recording the global transaction to be processed on the global blockchain corresponding to the first identifier in multiple global blockchains.

[0336] Steps 2210-2250 are described in detail below.

[0337] In step 2210, a local blockchain startup request refers to a request from a local consensus network to register its identity with the global consensus network for a specific blockchain. The global consensus network typically proactively sends the local blockchain startup request to the global consensus network. Then, in step 2220, the blockchain management contract is responsible for the startup registration of all local blockchains, calling the blockchain management contract to assign a first identifier to the local blockchain. Then, in step 2230, the first identifier is sent to the local consensus network. After receiving the first identifier, the local consensus network must also include the first identifier when subsequently sending pending local transactions to the global consensus network, allowing the global consensus network to determine the corresponding global blockchain based on the first identifier. Then, in step 310, in addition to receiving the pending local transaction and the first verification information, the global consensus network also receives the first identifier. After receiving the first identifier, in step 2250, the pending global transaction needs to be recorded on the global blockchain corresponding to the first identifier.

[0338] The advantage of this embodiment is that, even if the global consensus network aggregates pending local transactions, pending global transactions generated based on local transactions from different local blockchains should not be recorded on the same global blockchain, as this would compromise data isolation and security. This embodiment, however, assigns first identifiers to local blockchains and selects the corresponding global blockchain based on the first identifier when uploading data. This allows both uploading pending global transactions and data isolation between pending global transactions, further improving uploading security.

[0339] In one embodiment, before step 310, referring to FIG. 23 , the transaction on-chain method further includes:

[0340] Step 2310: Receive a registration request from the local consensus network;

[0341] Step 2320: Call the blockchain management contract to deploy the first verification contract and the second verification contract for the local consensus network;

[0342] Correspondingly, step 330 includes: step 2330, determining a local consensus network for recording the plurality of local blocks on the local blockchain; calling a first verification contract corresponding to the local consensus network, and performing a first verification based on block headers corresponding to the plurality of local blocks;

[0343] Correspondingly, step 340 includes: step 2340, calling the second verification contract corresponding to the local consensus network, and performing a second verification based on the local transaction to be processed, the first verification information and the block header of the local block to be processed.

[0344] Steps 2310-2340 are described in detail below.

[0345] In step 2310, the registration request refers to a request from the local consensus network to register an identity with the global consensus network. The registration request is generated by the local consensus network and sent by the local consensus network to the global consensus network.

[0346] In step 2320, in response to receiving the registration request, the global consensus network invokes the blockchain management contract to deploy the first and second verification contracts for the local consensus networks. The blockchain management contract is responsible for the startup registration of all local consensus networks, ID allocation, and registration of the first and second relay nodes. The blockchain management contract data serves as the data standard for each participant to determine the local consensus and authenticate the identities of each relay node. The first verification contract is the contract that verifies block headers. The second verification contract is the contract that verifies transactions.

[0347] In step 2330, when the local consensus network is registered with the "Blockchain Management Contract," the "Blockchain Management Contract" deploys a first verification contract for the local consensus network. This first verification contract receives, verifies, and stores the block header information submitted by the second relay node. For example, if the current block height is 100 and the second relay node submits five block headers at heights 101-105, the first verification contract will verify the integrity of the block header 101, primarily checking whether the digest value of the parent block header in the block header 101 matches the digest value of the block header 100 in the first verification contract, as well as the consensus information in the block header 101. After the first verification passes, the block header 101 is stored and the block headers 102-105 are verified sequentially. After the block header verification is completed, the first verification passes. The data from the first verification contract is provided to the "second verification contract" for transaction data verification.

[0348] In step 2340, the global consensus network receives the pending local transaction and the corresponding first verification information submitted by the first relay node of the corresponding local consensus network. For example, assume that the second verification contract receives a pending local transaction submitted from block height 101. During verification, the second verification contract first calculates the summary value of the pending local transaction based on the pending local transaction, and calculates the first root feature based on the first bypass feature of the first path submitted by the first relay node. The first root feature is then compared with the second root feature in the 101 block header obtained from the "first verification contract". If the comparison is successful, the second verification is successful.

[0349] The benefit of this embodiment is that the first verification contract is used to perform security verification of the pending local block where the pending local transaction is located, and the second verification contract is used to perform security verification of the pending local transaction itself. In this way, after both verifications are passed, the security of cross-chain transaction forwarding and the accuracy of global transaction on-chain are ensured.

[0350] Implementation details of the transaction chain method of this application embodiment

[0351] 24 , the implementation details of the transaction chaining method according to an embodiment of the present application will be described in detail.

[0352] Step 511: The first relay node identifies the local block added to the local blockchain;

[0353] Step 512: The first relay node checks the local transaction of the added local block, and if the local transaction has the first tag, obtains the local transaction as a pending local transaction;

[0354] Step 310 includes: Step 520, the global consensus node receives the to-be-processed local transaction and the first verification information from the first relay node;

[0355] Step 1711: The second relay node receives a first sending notification of a pending local block from the first relay node, where the first sending notification is sent after the first relay node sends the pending local transaction to the global consensus network.

[0356] Step 1712: In response to the first sending notification, the second relay node obtains the block header of the sent local block to be processed and sends it to the global consensus network;

[0357] Step 320 includes: Step 1720, the global consensus node receives block headers corresponding to multiple local blocks recorded on the local blockchain from the second relay node;

[0358] Step 330 includes: step 2330, determining a local consensus network for recording the plurality of local blocks on the local blockchain; calling a first verification contract corresponding to the local consensus network, and performing a first verification based on block headers corresponding to the plurality of local blocks;

[0359] Step 340 includes: step 2340, calling a second verification contract corresponding to the local consensus network, and performing a second verification based on the local transaction to be processed, the first verification information, and the block header of the local block to be processed;

[0360] Step 350: After both the first and second verifications are passed, a pending global transaction is generated based on the pending local transaction, and the pending global transaction is recorded on the global blockchain.

[0361] The advantages of this embodiment include but are not limited to: based on a multi-layer chain framework, it is suitable for large-scale businesses in the form of blockchain electronic invoices; the multi-layer chain form facilitates hierarchical business governance, which can ensure that each local blockchain can run local-level businesses relatively independently, and there is no need to aggregate all the traffic of the entire business alliance to the global blockchain; it plays the role of data isolation, business privacy isolation, and legal compliance, and can ensure that the global consensus network does not need to carry a large number of segmented businesses, and can also focus on key tasks and global governance; by judging whether the local transaction belongs to the transaction type specified in the business contract, and by adding the first mark to quickly distinguish whether the local transaction is used for aggregation, the local blockchain can standardize the selection of data messages sent back to the global blockchain, avoiding the return of a large amount of irrelevant data, ledgers, transaction information, etc. to the global blockchain, which can reduce The storage cost of the global blockchain is reduced and processing efficiency is improved. Through the second verification contract, the global blockchain can aggregate the ledger information of the local blockchain, based on which all data from the local blockchain can be verified trustlessly. The second relay node is used to send the block header to separate the transaction and block header transmission, and the synchronization of the pending local transaction and the block header is guaranteed by the first sending notification method, ensuring verification efficiency. By deploying the first verification contract and the second verification contract in advance, the efficiency and accuracy of the first and second verifications are improved. Through the entire protocol framework, a standardized, automated, and verifiable protocol for returning messages from the local blockchain to the global blockchain is provided. After both the first and second verifications are passed, the insecurity caused by third-party relay cheating or network transmission reasons is greatly reduced, and the security of cross-chain transaction forwarding and the accuracy of global transaction on-chain are improved.

[0362] Description of the apparatus and device of the embodiments of the present application

[0363] It is to be understood that, although the steps in the above-mentioned flowcharts are shown in sequence according to the arrow representations, these steps are not necessarily performed in sequence according to the order represented by the arrows. Unless otherwise specified in the present embodiment, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the above-mentioned flowcharts may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these steps or stages is not necessarily performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0364] It should be noted that in each specific embodiment of the present application, 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 such 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 target object's separate permission or separate consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the target object's separate permission or separate consent, the necessary target object-related data for the normal operation of the embodiment of the present application will be obtained.

[0365] FIG25 is a schematic diagram of the structure of a transaction on-chain device 2500 provided in an embodiment of the present application. The transaction on-chain device 2500 includes:

[0366] A first receiving unit 2510 is configured to receive a pending local transaction and first verification information corresponding to the pending local transaction, where the pending local transaction is located in a pending local block, which is recorded on a local blockchain.

[0367] A second receiving unit 2520 is configured to receive block headers corresponding to a plurality of local blocks recorded on the local blockchain, wherein the plurality of local blocks include a local block to be processed;

[0368] A first verification unit 2530 is configured to perform a first verification based on block headers corresponding to the plurality of local blocks;

[0369] A second verification unit 2540 is configured to perform a second verification based on the local transaction to be processed, the first verification information, and the block header of the local block to be processed;

[0370] The permission unit 2550 is configured to generate a pending global transaction based on the pending local transaction after both the first verification and the second verification are passed, and record the pending global transaction on the global blockchain.

[0371] In one possible implementation, the block header of the local block includes a first block body digest value of the local block and a second block body digest value of a previous local block of the local block on the local blockchain;

[0372] The first verification unit 2530 is specifically configured to:

[0373] Obtaining a first block body digest value from a block header of the local block to be processed, and obtaining a second block body digest value from a block header of a subsequent local block to the local block to be processed among the multiple local blocks;

[0374] The obtained first block body digest value is compared with the obtained second block body digest value to complete the first verification.

[0375] In a possible implementation, the first receiving unit 2510 is specifically configured to: receive a local transaction to be processed and first verification information from a first relay node;

[0376] The local transaction to be processed is obtained by the first relay node in the following way:

[0377] Identify local blocks added to the local blockchain;

[0378] Check the local transaction in the added local block, and if the local transaction has a first tag, obtain the local transaction as a pending local transaction, where the first tag indicates that the local transaction is used to generate a pending global transaction.

[0379] In one possible implementation, the first marker is added by the local consensus network that records the local blockchain in the following manner:

[0380] Get local transactions;

[0381] Run the local consensus business contract and identify the transaction type specified in the local consensus business contract;

[0382] If the local transaction belongs to the specified transaction type, a first marker is added to the local transaction.

[0383] In a possible implementation, the first verification information is obtained by the first relay node in the following manner:

[0384] Generate a first tree, the first tree including multiple layers of features, wherein the bottom layer of the first tree is the summary value of multiple local transactions in the local block to be processed, the multiple local transactions including the local transaction to be processed; two adjacent features in each layer of the first tree are connected to and generate a feature in the next layer, until a first root feature of the first tree is generated, the first root feature being the summary value of the first block body;

[0385] Obtaining a first bypass feature of the first path as first verification information, wherein the first path is the path between the summary value of the local transaction to be processed on the first tree and the first tree root feature, and the first bypass feature is the next layer feature to which features other than the summary value of the local transaction to be processed on the first path are connected;

[0386] The second verification unit 2540 is specifically configured to:

[0387] Determine the summary value of the pending local transaction;

[0388] Determining a second root feature of the first tree based on the digest value of the local transaction to be processed and the first verification information;

[0389] The second tree root feature is compared with the first block body summary value to complete the second verification.

[0390] In one possible implementation, the global consensus node is located on the global consensus network; the pending local transaction is sent by the first relay node to the global consensus network in the following manner:

[0391] Determine the transaction type of the local transaction to be processed;

[0392] Based on the transaction type, the pending local transaction is placed in the queue corresponding to the transaction type;

[0393] If the queue meets the predetermined conditions, the pending local transactions in the queue are taken out and sent to the global consensus network.

[0394] In one possible implementation, if a queue meets a predetermined condition, the pending local transaction in the queue is taken out and sent to the global consensus network, including:

[0395] If the number of pending local transactions in the queue reaches a first threshold, the pending local transactions in the queue are taken out and sent to the global consensus network;

[0396] If the number of pending local transactions in the queue does not reach a first threshold, determining a time difference between the current time and the time when the pending local transaction was last sent to the global consensus network;

[0397] If the time difference reaches the second threshold, the pending local transaction in the queue is taken out and sent to the global consensus network.

[0398] In one possible implementation, the global consensus node is located on the global consensus network;

[0399] The pending local transaction is sent to the global consensus network by the first relay node in the following way:

[0400] Get the transaction priority and timestamp of the pending local transaction;

[0401] Determine the processing order of pending local transactions based on transaction priority and timestamp;

[0402] Put the pending local transactions into the local transaction queue according to the processing order;

[0403] In the order of processing, the pending local transactions are taken out from the local transaction queue and sent to the global consensus network.

[0404] In one possible implementation, determining the processing order of pending local transactions in a pending local transaction queue based on transaction priorities and timestamps includes:

[0405] Determine a first score of the pending local transaction based on the transaction priority;

[0406] Determining a second score of the pending local transaction based on a difference between the timestamp and the current time;

[0407] Determining a total score of the pending local transaction based on the first score and the second score;

[0408] Based on the total score, the processing order of the pending local transactions is determined.

[0409] In one possible implementation, the second receiving unit 2520 is specifically configured to: receive, from the second relay node, block headers corresponding to a plurality of local blocks recorded on the local blockchain;

[0410] The block header of the local block to be processed is sent to the global consensus network by the second relay node in the following way:

[0411] receiving a first sending notification of a pending local block from a first relay node, the first sending notification being sent after the first relay node sends the pending local transaction to the global consensus network;

[0412] In response to the first sending notification, the block header of the sent local block to be processed is obtained and sent to the global consensus network.

[0413] In a possible implementation, the allowing unit 2550 is specifically configured to:

[0414] When both the first and second verifications are passed, the transaction type of the pending local transaction is obtained;

[0415] Call the global consensus business contract corresponding to the transaction type;

[0416] Execute the global consensus business contract to generate pending global transactions based on pending local transactions and record the pending global transactions on the global blockchain.

[0417] In one possible implementation, the local blockchain is a plurality of local blockchains, and the global blockchain is a plurality of global blockchains corresponding to the plurality of local blockchains;

[0418] The first receiving unit 2510 is specifically configured to receive a local transaction to be processed, first verification information, and a first identifier of a local blockchain;

[0419] The allowing unit 2550 is further specifically configured to record the pending global transaction on a global blockchain corresponding to the first identifier in one of the multiple global blockchains.

[0420] In one possible implementation, before receiving the local transaction to be processed, the first verification information, and the first identifier of the local blockchain, the transaction on-chain apparatus further includes:

[0421] A third receiving unit (not shown), configured to receive a local blockchain startup request from the local consensus network;

[0422] an allocation unit (not shown), configured to respond to a local blockchain startup request, call a blockchain management contract, and allocate a first identifier to the local blockchain;

[0423] The first sending unit (not shown) is used to send the first identifier to the local consensus network.

[0424] In one possible implementation, before receiving the to-be-processed local transaction and the first verification information corresponding to the to-be-processed local transaction, the transaction on-chain apparatus further includes:

[0425] a fourth receiving unit (not shown), configured to receive a first authentication request from the first relay node, wherein the local transaction to be processed is received from the first relay node, and the first authentication request includes first information to be authenticated;

[0426] A first authentication unit (not shown), configured to call a blockchain management contract to perform a first authentication on the first information to be authenticated;

[0427] A second sending unit (not shown), configured to send the first token to the first relay node through the blockchain management contract if the first authentication is passed;

[0428] The first receiving unit 2510 is specifically configured to:

[0429] A local transaction to be processed, first verification information, and a second token are received from a first relay node, where the second token is used for comparison with the first token.

[0430] In one possible implementation, before receiving the to-be-processed local transaction and the first verification information corresponding to the to-be-processed local transaction, the transaction on-chain apparatus further includes:

[0431] a fifth receiving unit (not shown), configured to receive a second authentication request from a second relay node, wherein the block headers corresponding to the plurality of local blocks are received from the second relay node, and the second authentication request includes second information to be authenticated;

[0432] A second authentication unit (not shown), configured to call the blockchain management contract to perform a second authentication on the second information to be authenticated;

[0433] a third sending unit (not shown), configured to send a third token to the second relay node through the blockchain management contract if the second authentication passes;

[0434] The second receiving unit 2520 is specifically configured to:

[0435] The block headers and the fourth token corresponding to the multiple local blocks recorded on the local blockchain are received from the second relay node, and the fourth token is used for comparison with the third token.

[0436] In one possible implementation, before receiving the to-be-processed local transaction and the first verification information corresponding to the to-be-processed local transaction, the transaction on-chain apparatus further includes:

[0437] A sixth receiving unit (not shown), configured to receive a registration request from a local consensus network;

[0438] A deployment unit (not shown), configured to call the blockchain management contract and deploy the first verification contract and the second verification contract for the local consensus network;

[0439] The first verification unit 2530 is specifically configured to: determine a local consensus network for recording the plurality of local blocks on the local blockchain; call a first verification contract corresponding to the local consensus network, and perform a first verification based on the block headers corresponding to the plurality of local blocks;

[0440] The second verification unit 2540 is specifically used to call the second verification contract corresponding to the local consensus network, and perform a second verification based on the local transaction to be processed, the first verification information and the block header of the local block to be processed.

[0441] 26 , which is a block diagram of a portion of a terminal that implements the transaction on-chain method according to an embodiment of the present application. The terminal includes components such as a radio frequency (RF) circuit 2610, a memory 2615, an input unit 2630, a display unit 2640, a sensor 2650, an audio circuit 2660, a wireless fidelity (WiFi) module 2670, a processor 2680, and a power supply 2690. Those skilled in the art will appreciate that the terminal structure shown in FIG26 does not limit the scope of a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or arrange the components differently.

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

[0443] The memory 2615 may be used to store software programs and modules. The processor 2680 executes various functional applications and data processing of the target terminal by running the software programs and modules stored in the memory 2615 .

[0444] The input unit 2630 may be configured to receive input digital or character information and generate key signal input related to the setting and function control of the target terminal. Specifically, the input unit 2630 may include a touch panel 2631 and other input devices 2632.

[0445] The display unit 2640 may be configured to display input information or provided information and various menus of the target terminal. The display unit 2640 may include a display panel 2641.

[0446] The audio circuit 2660 , the speaker 2661 , and the microphone 2662 may provide an audio interface.

[0447] In this embodiment, the processor 2680 included in the terminal can execute the transaction on-chain method of the previous embodiment.

[0448] The terminals of the embodiments of the present application 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 data security, blockchain, data storage, information technology, etc.

[0449] Figure 27 is a block diagram of the structure of part of the server for implementing the transaction chain method of an embodiment of the present application. The server may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 2722 (for example, one or more processors) and memories 2732, and one or more storage media 2730 (for example, one or more mass storage devices) for storing application programs 2742 or data 2744. Among them, the memories 2732 and the storage media 2730 can be temporary storage or permanent storage. The program stored in the storage medium 2730 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Furthermore, the central processing unit 2722 can be configured to communicate with the storage medium 2730 to execute a series of instruction operations in the storage medium 2730 on the server.

[0450] The server may also include one or more power supplies 2726, one or more wired or wireless network interfaces 2750, one or more input and output interfaces 2758, and / or one or more operating systems 2741, such as Windows Server 2003. TM , Mac OS X TM , Unix TM , Linux TM , FreeBSD TM etc.

[0451] The central processor 2722 in the server can be used to execute the transaction chaining method of the embodiment of the present application.

[0452] An embodiment of the present application also provides a computer-readable storage medium, which is used to store a computer program, and the computer program is used to execute the transaction chaining method of each of the aforementioned embodiments.

[0453] The present application 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 the above-mentioned transaction on-chain method.

[0454] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the numbers used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprise" 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 clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0455] It should be understood that in this application, "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 previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items 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.

[0456] It should be understood that in the description of the embodiments of the present application, multiple (or multiple items) means more than two, greater than, less than, exceed, etc. are understood to exclude the number itself, and above, below, within, etc. are understood to include the number itself.

[0457] In the several embodiments provided in this application, 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 merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, such as 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 interface, device or unit, which can be electrical, mechanical or other forms.

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

[0459] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0460] 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 application, 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, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0461] It should also be understood that the various implementation methods provided in the embodiments of the present application can be combined arbitrarily to achieve different technical effects.

[0462] The above is a specific description of the implementation methods of the present application, but the present application 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 application. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present application.

Claims

1. A transaction on-chain method, the method being executed by a global consensus node, comprising: Receiving a local transaction to be processed and first verification information corresponding to the local transaction to be processed, wherein the local transaction to be processed is located in a local block to be processed, and the local block to be processed is recorded on a local blockchain; Receiving block headers respectively corresponding to a plurality of local blocks recorded on the local blockchain, wherein the plurality of local blocks include the local block to be processed; Performing a first verification based on the block headers respectively corresponding to the plurality of local blocks; Performing a second verification based on the to-be-processed local transaction, the first verification information, and the block header of the to-be-processed local block; When both the first verification and the second verification are passed, a pending global transaction is generated based on the pending local transaction, and the pending global transaction is recorded on the global blockchain.

2. According to the transaction chaining method of claim 1, the block header of the local block includes a first block body digest value of the local block and a second block body digest value of a previous local block of the local block on the local blockchain; The first verification based on the block headers of the plurality of local blocks includes: Acquire a first block body digest value from a block header of the to-be-processed local block, and acquire a second block body digest value from a block header of a subsequent local block of the to-be-processed local block among the multiple local blocks; The obtained first block body digest value is compared with the obtained second block body digest value to complete the first verification.

3. According to the transaction on-chain method of claim 1, the receiving of the pending local transaction and the first verification information corresponding to the pending local transaction comprises: receiving the to-be-processed local transaction and the first verification information from a first relay node; The to-be-processed local transaction is acquired by the first relay node in the following manner: Identifying a local block added to the local blockchain; Check the local transaction in the added local block, and if the local transaction has a first tag, obtain the local transaction as the to-be-processed local transaction, wherein the first tag indicates that the local transaction is used to generate the to-be-processed global transaction.

4. According to the transaction chain method of claim 3, the first mark is added by the local consensus network recording the local blockchain in the following manner: Obtaining the local transaction; Running a local consensus business contract and identifying the transaction type specified in the local consensus business contract; If the local transaction belongs to the specified transaction type, the first tag is added to the local transaction.

5. According to the transaction on-chain method of claim 3, the first verification information is obtained by the first relay node in the following manner: A first tree is generated, the first tree comprising multiple layers of features, wherein: The bottom layer feature of the first tree is the summary value of multiple local transactions in the local block to be processed, and the multiple local transactions include the local transaction to be processed; two adjacent features of each layer of the first tree are connected to and generate a feature of a higher layer, until a first tree root feature of the first tree is generated, and the first tree root feature is the summary value of the first block body; Acquire a first bypass feature of a first path as the first verification information, wherein the first path is a path between the summary value of the to-be-processed local transaction on the first tree and the first tree root feature, and the first bypass feature is a next-layer feature to which other features on the first path except the summary value of the to-be-processed local transaction are connected; The performing a second verification based on the to-be-processed local transaction, the first verification information, and the block header of the to-be-processed local block includes: Determining a summary value of the local transaction to be processed; Determine a second tree root feature of the first tree based on the summary value of the local transaction to be processed and the first verification information; The second tree root feature is compared with the first block body summary value to complete the second verification.

6. According to the transaction chain method of claim 3, the global consensus node is located on the global consensus network; The pending local transaction is sent by the first relay node to the global consensus network in the following manner: Determining the transaction type of the local transaction to be processed; Based on the transaction type, placing the to-be-processed local transaction into a queue corresponding to the transaction type; If the queue meets a predetermined condition, the pending local transaction in the queue is taken out, and the pending local transaction is sent to the global consensus network.

7. The transaction on-chain method according to claim 6, wherein if the queue meets a predetermined condition, the pending local transaction in the queue is taken out, and the pending local transaction is sent to the global consensus network, comprising: If the number of pending local transactions in the queue reaches a first threshold, taking out the pending local transactions in the queue, and sending the pending local transactions to the global consensus network; If the number of the pending local transactions in the queue does not reach the first threshold, determining a time difference between a current time and a time when the pending local transaction was last sent to the global consensus network; If the time difference reaches a second threshold, the pending local transaction in the queue is taken out, and the pending local transaction is sent to the global consensus network.

8. The transaction on-chain method according to claim 3, wherein the global consensus node is located on the global consensus network; The pending local transaction is sent by the first relay node to the global consensus network in the following manner: Obtaining the transaction priority and timestamp of the pending local transaction; Determining a processing order of the to-be-processed local transactions based on the transaction priority and the timestamp; According to the processing order, the to-be-processed local transaction is placed into a local transaction queue; According to the processing order, the pending local transactions are taken out from the local transaction queue, and the pending local transactions are sent to the global consensus network.

9. According to the transaction chain method of claim 8, determining the processing order of the pending local transactions based on the transaction priority and the timestamp comprises: Based on the transaction priority, determining a first score of the pending local transaction; Determining a second score of the pending local transaction based on a difference between the timestamp and the current time; Determine a total score of the to-be-processed local transaction based on the first score and the second score; Based on the total score, a processing order of the to-be-processed local transactions is determined.

10. According to the transaction on-chain method of claim 3, the receiving of block headers corresponding to the plurality of local blocks recorded on the local blockchain comprises: Receive, from the second relay node, block headers corresponding to the multiple local blocks recorded on the local blockchain; The block header of the local block to be processed is sent by the second relay node to the global consensus network in the following manner: receiving a first sending notification of the pending local block from the first relay node, wherein the first sending notification is sent after the first relay node sends the pending local transaction to the global consensus network; In response to the first sending notification, the block header of the sent local block to be processed is obtained and sent to the global consensus network.

11. The transaction on-chain method according to claim 1, wherein when both the first verification and the second verification are passed, generating a pending global transaction based on the pending local transaction, and recording the pending global transaction on the global blockchain, comprises: When both the first verification and the second verification are passed, obtaining the transaction type of the to-be-processed local transaction; Calling the global consensus business contract corresponding to the transaction type; The global consensus business contract is executed to generate the pending global transaction based on the pending local transaction, and the pending global transaction is recorded on the global blockchain.

12. The transaction on-chain method according to claim 11, wherein the local blockchain is a plurality of local blockchains, and the global blockchain is a plurality of global blockchains corresponding to the plurality of local blockchains; The receiving a local transaction to be processed and first verification information corresponding to the local transaction to be processed includes: receiving the local transaction to be processed, the first verification information, and a first identifier of the local blockchain; The recording of the pending global transaction on the global blockchain includes: recording the pending global transaction on a global blockchain corresponding to the first identifier among the multiple global blockchains.

13. According to the transaction on-chain method of claim 12, before receiving the to-be-processed local transaction, the first verification information and the first identifier of the local blockchain, the transaction on-chain method further comprises: Receive a local blockchain startup request from the local consensus network; In response to the local blockchain startup request, calling a blockchain management contract to allocate the first identifier to the local blockchain; The first identifier is sent to the local consensus network.

14. According to the transaction chain method of claim 1, before receiving the pending local transaction and the first verification information corresponding to the pending local transaction, the transaction chain method further comprises: receiving a first authentication request from a first relay node, wherein the local transaction to be processed is received from the first relay node, and the first authentication request has first information to be authenticated; Calling a blockchain management contract to perform a first authentication on the first information to be authenticated; If the first authentication passes, sending a first token to the first relay node through the blockchain management contract; The receiving of the to-be-processed local transaction and the first verification information corresponding to the to-be-processed local transaction includes: The to-be-processed local transaction, the first verification information, and a second token are received from the first relay node, where the second token is used for comparison with the first token.

15. According to the transaction chaining method of claim 1, before receiving the pending local transaction and the first verification information corresponding to the pending local transaction, the transaction chaining method further comprises: receiving a second authentication request from a second relay node, wherein the block headers corresponding to the plurality of local blocks are received from the second relay node, and the second authentication request has second information to be authenticated; Calling the blockchain management contract to perform a second authentication on the second information to be authenticated; If the second authentication passes, sending a third token to the second relay node through the blockchain management contract; The receiving block headers of the plurality of local blocks recorded on the local blockchain includes: Receive block headers and a fourth token respectively corresponding to multiple local blocks recorded on the local blockchain from the second relay node, and the fourth token is used to compare with the third token.

16. The transaction chaining method according to claim 1, before receiving the pending local transaction and the first verification information corresponding to the pending local transaction, the transaction chaining method further comprises: Receive registration requests from local consensus networks; Calling a blockchain management contract to deploy a first verification contract and a second verification contract for the local consensus network; The performing of the first verification based on the block headers respectively corresponding to the plurality of the local blocks includes: determining a local consensus network that records the plurality of the local blocks on the local blockchain; calling the first verification contract corresponding to the local consensus network, and performing the first verification based on the block headers respectively corresponding to the plurality of the local blocks; The performing a second verification based on the local transaction to be processed, the first verification information and the block header of the local block to be processed includes: calling the second verification contract corresponding to the local consensus network, and performing the second verification based on the local transaction to be processed, the first verification information and the block header of the local block to be processed.

17. A transaction on-chain device, the device being deployed on a global consensus node, comprising: A first receiving unit is used to receive a local transaction to be processed and first verification information corresponding to the local transaction to be processed, wherein the local transaction to be processed is located in a local block to be processed, and the local block to be processed is recorded on a local blockchain; A second receiving unit is used to receive block headers corresponding to a plurality of local blocks recorded on the local blockchain, wherein the plurality of local blocks include the local block to be processed; A first verification unit, configured to perform a first verification based on block headers respectively corresponding to the plurality of local blocks; A second verification unit, configured to perform a second verification based on the local transaction to be processed, the first verification information, and a block header of the local block to be processed; The permission unit is used to generate a pending global transaction based on the pending local transaction when both the first verification and the second verification are passed, and record the pending global transaction on the global blockchain.

18. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the transaction chain method according to any one of claims 1 to 16 when executing the computer program.

19. A computer-readable storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the transaction chaining method according to any one of claims 1 to 16 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 transaction chaining method according to any one of claims 1 to 16.

Images