Blockchain transaction processing method, related apparatus and medium

Abstract

This disclosure provides a blockchain transaction processing method, related apparatus, and medium. The method includes: within a current broadcast cycle, determining multiple candidate transaction groups based on multiple transactions to be uploaded to the blockchain from a first transaction pool; determining a target transaction group from the multiple candidate transaction groups based on the total number of transaction broadcasts by a first blockchain node; sending a first transaction digest of the transactions in the target transaction group to a second blockchain node in the blockchain network, so that the second blockchain node determines a target transaction digest based on the second transaction digests of the transactions to be uploaded to the blockchain from the second transaction pool and the first transaction digests of the transactions in the target transaction group, and returns the target transaction digest to the first blockchain node; extracting transaction data of the target transactions whose first transaction digest matches the target transaction digest from the target transaction group and broadcasting it to the second blockchain node. This disclosure improves transaction broadcasting efficiency. This disclosure can be applied to various scenarios such as blockchain, artificial intelligence, and cloud technology.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to a blockchain transaction processing method, related apparatus and medium. Background Technology

[0002] In a blockchain network, each blockchain node frequently receives transactions submitted by different end-users, awaiting to be uploaded to the blockchain. After receiving these transactions, blockchain nodes often broadcast them to other nodes. For example, if a blockchain node receives a transaction, it will directly send it to all other blockchain nodes except itself.

[0003] However, for transactions with low on-chain resource overhead, even if they are quickly broadcast in the blockchain network, they are often packaged and uploaded to the blockchain in a short period of time, leading to high load on blockchain nodes. This is because blockchain nodes often prioritize packaging and uploading transactions with higher on-chain resource overhead. Simultaneously, some client devices may submit the same transaction to multiple blockchain nodes. If blockchain nodes broadcast all received transactions indiscriminately, it often results in duplicate broadcasts. For example, if a client device submits the same transaction to both blockchain node A and blockchain node B, nodes A and B will still broadcast the same transaction to each other, causing unnecessary broadcast overhead and inefficient transaction broadcasting. Summary of the Invention

[0004] This disclosure provides a blockchain transaction processing method, related apparatus, and medium that can improve transaction broadcasting efficiency while reducing the resource overhead of broadcasting transactions in a blockchain network.

[0005] According to one aspect of this disclosure, a blockchain transaction processing method is provided, executed by a first blockchain node in a blockchain network, the method comprising:

[0006] Within the current broadcast cycle, multiple candidate transaction groups are determined based on the multiple transactions to be uploaded to the chain in the first transaction pool that are maintained;

[0007] Based on the total number of transaction broadcasts by the first blockchain node, the target transaction group is determined from the plurality of candidate transaction groups;

[0008] The first transaction digests of each of the multiple transactions in the target transaction group are sent to the second blockchain node in the blockchain network, so that the second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be put on the chain in the maintained second transaction pool and the first transaction digests of each of the multiple transactions, and returns the target transaction digest to the first blockchain node;

[0009] Based on the target transaction digest received from the second blockchain node, target transactions whose first transaction digest matches the target transaction digest are extracted from the target transaction group, and the transaction data of the target transaction is broadcast to the second blockchain node.

[0010] According to one aspect of this disclosure, a blockchain transaction processing apparatus is provided, executed by a first blockchain node in a blockchain network, the apparatus comprising:

[0011] The first determining unit is used to determine multiple candidate transaction groups based on multiple transactions to be uploaded to the chain in the maintained first transaction pool during the current broadcast period.

[0012] The second determining unit is used to determine the target transaction group from the plurality of candidate transaction groups based on the total number of transaction broadcasts by the first blockchain node.

[0013] The sending unit is configured to send the first transaction digests of each of the multiple transactions in the target transaction group to a second blockchain node in the blockchain network, so that the second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be uploaded to the chain in the maintained second transaction pool and the first transaction digests of each of the multiple transactions, and returns the target transaction digest to the first blockchain node;

[0014] The broadcasting unit is configured to extract the target transaction whose first transaction digest matches the target transaction digest from the target transaction group based on the target transaction digest received from the second blockchain node, and broadcast the transaction data of the target transaction to the second blockchain node.

[0015] Optionally, the first determining unit includes:

[0016] The extraction module is used to extract a first number of transactions to be uploaded to the chain as candidate transactions from the first transaction pool, wherein the first number is less than the total number of transactions to be uploaded to the chain in the first transaction pool.

[0017] The grouping module is used to group the candidate transactions based on the first number and the maximum number of transactions within the candidate transaction group to obtain the multiple candidate transaction groups, so that the total number of candidate transactions in each candidate transaction group is not greater than the maximum number of transactions within the group.

[0018] Optionally, the extraction module is used for:

[0019] In the first transaction pool, the on-chain resource overhead of each of the plurality of transactions to be on-chain is determined;

[0020] The first number of transactions to be added to the chain with the resource overhead being greater than or equal to the first threshold are selected as candidate transactions.

[0021] Optionally, the extraction module is used for:

[0022] In the first transaction pool, the time difference between the transaction timestamp and the current time is determined for each of the multiple transactions to be uploaded to the blockchain;

[0023] The first number of transactions to be added to the chain with a time difference greater than or equal to the second threshold are selected as candidate transactions.

[0024] Optionally, the extraction module is used for:

[0025] In the first transaction pool, the on-chain resource cost of each of the multiple transactions to be on-chain, and the time difference between the transaction timestamp of each of the multiple transactions to be on-chain and the current time are determined.

[0026] For each transaction to be uploaded to the blockchain, the transaction score of the transaction to be uploaded to the blockchain is determined based on the blockchain resource overhead and the time difference;

[0027] The first number of transactions to be added to the chain whose transaction scores are greater than or equal to the third threshold are selected as candidate transactions.

[0028] Optionally, the grouping module includes:

[0029] The determination submodule is used to determine the number of groups of the plurality of candidate transaction groups based on the quotient of the first number and the maximum number of transactions within the group;

[0030] The allocation submodule is used to allocate the candidate transactions to the candidate transaction groups based on the number of groups, so that each candidate transaction is assigned to one candidate transaction group.

[0031] Optionally, the allocation submodule is used for:

[0032] The candidate transactions are sorted to obtain the transaction order;

[0033] The anchor transaction group is initialized as the first candidate transaction group among the plurality of candidate transaction groups;

[0034] Based on the transaction order, the unallocated candidate transactions are sequentially filled into the anchor transaction group until the total number of candidate transactions in the anchor transaction group equals the maximum number of transactions in the group. The anchor transaction group is then updated with the next candidate transaction group, and the process returns to the step of sequentially filling the unallocated candidate transactions into the anchor transaction group based on the transaction order until all candidate transactions are allocated.

[0035] Optionally, sorting the candidate transactions to obtain the transaction order includes:

[0036] For each of the candidate transactions, determine the resource gain that the first blockchain node can obtain on the candidate transaction;

[0037] Based on the resource gain, the candidate transactions are sorted to obtain the transaction order.

[0038] Optionally, the second determining unit is used to:

[0039] Determine the number of candidate transaction groups and the group index of each candidate transaction group;

[0040] The target remainder is obtained by performing a modulo operation based on the number of groups and the total number of transaction broadcasts.

[0041] The target transaction group is determined from the plurality of candidate transaction groups based on the target remainder and the grouping index.

[0042] Optionally, the sending unit is used for:

[0043] For multiple transactions to be uploaded to the blockchain in the maintained second transaction pool, a digest operation is performed on the transaction data of each of the multiple transactions to be uploaded to the blockchain to obtain the second transaction digest of each of the multiple transactions to be uploaded to the blockchain.

[0044] The first transaction digest that is different from the second transaction digest is determined as the target transaction digest.

[0045] Optionally, there may be multiple target transaction summaries, and there may be multiple target transactions;

[0046] The sending unit is used for:

[0047] Multiple target transaction digests are integrated into a digest array, and the digest array is returned to the first blockchain node;

[0048] The broadcast unit is used for:

[0049] The transaction data of the target transaction is integrated into a transaction data array, and the transaction data array is broadcast to the second blockchain node.

[0050] Optionally, the maximum number of transactions within a candidate transaction group is determined in the following way:

[0051] The third determining unit is used to determine the operating status parameters and load status parameters of the first blockchain node in the previous broadcast cycle of the current broadcast cycle.

[0052] The fourth determining unit is used to determine the node performance score of the first blockchain node based on the operating status parameters and the load status parameters.

[0053] The fifth determining unit is used to determine the maximum number of transactions within the group based on the node performance score.

[0054] Optionally, the operating status parameters include the data transmission rate and packet loss rate of the first blockchain node in the previous broadcast cycle, and the load status parameters include the CPU utilization, memory utilization, and bandwidth utilization of the first blockchain node in the previous broadcast cycle.

[0055] The fourth determining unit is used for:

[0056] A first score is determined based on the data transmission rate and the packet loss rate;

[0057] The second score is determined based on the CPU utilization, memory utilization, and bandwidth utilization.

[0058] The node performance score is determined based on the first score and the second score.

[0059] Optionally, the duration of the current broadcast period is determined in the following way:

[0060] Determine the network bandwidth and network structure of the blockchain network;

[0061] The network score of the blockchain network is determined based on the network bandwidth and the network structure.

[0062] The period duration is determined based on the network score.

[0063] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the blockchain transaction processing method as described above.

[0064] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the blockchain transaction processing method as described above.

[0065] According to one aspect of this disclosure, a computer program product is provided, the computer program product including a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the blockchain transaction processing method as described above.

[0066] In this embodiment, considering the amount of data that the network bandwidth of the blockchain network allows to transmit, a method of periodically broadcasting transactions to be uploaded to the blockchain in groups is provided. Specifically, when the first blockchain node broadcasts transactions, within the current broadcast period, the first blockchain node first divides the multiple transactions to be uploaded to the blockchain in its maintained first transaction pool into multiple candidate transaction groups, so that each candidate transaction group contains only a portion of the transactions to be uploaded to the blockchain; then, based on the total number of transaction broadcasts by the first blockchain node, the target transaction group is determined from the multiple candidate transaction groups. In this way, only the transactions to be uploaded to the blockchain in the target transaction group are broadcast in the current broadcast period, which can reduce the node load. Furthermore, in this embodiment, the transactions to be uploaded to the blockchain in the target transaction group are not broadcast directly. Instead, the first transaction digests of each of the multiple transactions in the target transaction group are first sent to the second blockchain node in the blockchain network. The second blockchain node then queries which transactions to be uploaded to the blockchain are missing in its maintained second transaction pool based on the first transaction digests, and returns the first transaction digests corresponding to these missing transactions as the target transaction digests. In this way, the first blockchain node only needs to broadcast the transaction data of the target transaction corresponding to the target transaction digest to the second blockchain node, instead of broadcasting all transactions to be uploaded to the blockchain in the target transaction group. This approach effectively reduces the duplicate broadcasting of transactions to be uploaded to the blockchain, broadcasting only the portion of transactions to be uploaded to the blockchain that differ in the transaction pools of each blockchain node. This reduces the resource overhead of broadcasting transactions in the blockchain network while improving the efficiency of transaction broadcasting.

[0067] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0068] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0069] Figure 1 This is a system architecture diagram of a blockchain transaction processing method applied according to an embodiment of the present disclosure;

[0070] Figures 2A-2E A schematic diagram is shown illustrating the application of a blockchain transaction processing method according to an embodiment of the present disclosure in a transaction on-chain scenario;

[0071] Figure 3 This is a flowchart of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0072] Figure 4 This is a flowchart of grouping candidate transactions according to an embodiment of the present disclosure;

[0073] Figure 5 This is a flowchart illustrating the determination of multiple candidate transactions according to an embodiment of the present disclosure;

[0074] Figure 6 This is a flowchart of determining a plurality of candidate transactions according to another embodiment of the present disclosure;

[0075] Figure 7 This is a flowchart of determining a plurality of candidate transactions according to another embodiment of the present disclosure;

[0076] Figures 8A-8C This is a schematic diagram illustrating the process of determining multiple candidate transactions according to an embodiment of the present disclosure;

[0077] Figure 9 This is a flowchart illustrating the assignment of candidate transactions to candidate transaction groups according to an embodiment of the present disclosure;

[0078] Figure 10 This is a schematic diagram illustrating the process of grouping candidate transactions according to an embodiment of the present disclosure;

[0079] Figure 11 This is a flowchart illustrating the assignment of candidate transactions to candidate transaction groups according to an embodiment of the present disclosure;

[0080] Figure 12 This is a flowchart illustrating the generation of transaction sequence according to an embodiment of the present disclosure;

[0081] Figures 13A-13B This is a schematic diagram illustrating the implementation process of assigning candidate transactions to candidate transaction groups according to an embodiment of the present disclosure;

[0082] Figure 14 This is a flowchart illustrating the determination of the maximum number of transactions within a group according to an embodiment of this disclosure;

[0083] Figure 15This is a flowchart of determining a node performance score according to an embodiment of the present disclosure;

[0084] Figure 16 This is a flowchart illustrating the determination of a cycle duration according to an embodiment of the present disclosure;

[0085] Figure 17 This is a flowchart of determining a target transaction group according to an embodiment of the present disclosure;

[0086] Figure 18 This is a schematic diagram illustrating the process of determining a target transaction group according to an embodiment of the present disclosure;

[0087] Figure 19 This is a flowchart illustrating the determination of a target transaction summary according to an embodiment of the present disclosure;

[0088] Figures 20A-20B This is a schematic diagram illustrating the implementation details of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0089] Figure 21 This is a schematic diagram illustrating the implementation details of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0090] Figure 22 This is a block diagram of a blockchain transaction processing apparatus according to an embodiment of the present disclosure;

[0091] Figure 23 This is a terminal structure diagram of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0092] Figure 24 This is a server architecture diagram of a blockchain transaction processing method according to an embodiment of the present disclosure. Detailed Implementation

[0093] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0094] The system architecture and scenarios in which this disclosure is applied are described below.

[0095] Figure 1 This is a system architecture diagram of the blockchain transaction processing method applied according to embodiments of this disclosure. It includes an object terminal 140, an Internet 130, a gateway 120, a server 110, etc.

[0096] The object terminal 140 includes various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. The object terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data. The object terminal 140 includes a transaction processing platform, which is used to submit various information to be recorded on the blockchain to the blockchain network.

[0097] See Figure 1 The server 110 shown includes a consensus network 160. The consensus network 160 refers to the network that reaches a consensus on transactions to be added to the blockchain before adding them to the blockchain; it includes multiple consensus nodes. A consensus node is a blockchain node. A consensus node or blockchain node can be a server within server 110 or an object terminal connected to server 110; the specific form of the consensus node or blockchain node is not limited here.

[0098] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from target terminal 140 to server 110 are forwarded to the corresponding server 110 via gateway 120. Messages sent from server 110 to target terminal 140 are also forwarded to the corresponding target terminal 140 via gateway 120.

[0099] The embodiments disclosed herein can be applied in various scenarios, such as Figures 2A-2E The example shown is a transaction broadcasting scenario, etc.

[0100] like Figure 2A As shown, a blockchain network includes four blockchain nodes: blockchain node 1, blockchain node 2, blockchain node 3, and blockchain node 4. Each of these nodes is directly connected to the next. When an object submits a transaction to blockchain node 1, blockchain node 1, upon receiving the transaction, can broadcast it to blockchain nodes 2, 3, and 4 respectively. Furthermore, when an object submits a transaction to the blockchain network, it can also submit the transaction to multiple blockchain nodes (e.g., blockchain node 1 and blockchain node 2).

[0101] like Figure 2BAs shown, in a blockchain network, before each blockchain node broadcasts the transactions to be uploaded to the chain received from various objects, the transactions to be uploaded to the chain in the transaction pools maintained by each blockchain node will differ to some extent. Specifically, blockchain node 1's transaction pool includes 7 transactions to be uploaded to the chain, namely, Transaction 1, Transaction 2, Transaction 3, Transaction 4, Transaction 5, Transaction 6, and Transaction 7; blockchain node 2's transaction pool includes 5 transactions to be uploaded to the chain, namely, Transaction 1, Transaction 2, Transaction 3, Transaction 8, and Transaction 9.

[0102] like Figure 2C As shown, after receiving multiple transactions to be uploaded to the blockchain, blockchain node 1 groups these transactions into three groups: Group 1, Group 2, and Group 3. Group 1 includes transactions 1, 3, and 5; Group 2 includes transactions 2, 4, and 6; and Group 3 includes transaction 7. Next, Group 2 is selected from Groups 1, 2, and 3. The transaction summaries of transactions 2, 4, and 6 in Group 2 are then integrated to obtain a single integrated transaction summary. This integrated transaction summary includes the transaction summary of transaction 2 (xxfaf13), the transaction summary of transaction 4 (tr46dqr), and the transaction summary of transaction 6 (wqa98op). Finally, blockchain node 1 broadcasts the integrated transaction summary to blockchain nodes 2, 3, and 4.

[0103] like Figure 2D As shown, when blockchain node 2 receives the transaction digest integration data broadcast by blockchain node 1, blockchain node 2 compares the transaction digest recorded in the integration data with the transaction digests of each transaction to be added to the blockchain in its own transaction pool. It then extracts the transaction digests that differ from those of the transactions to be added to the blockchain in its own pool. Specifically, the extracted transaction digests are tr46dqr for transaction 4 and wqa98op for transaction 6. Based on this, blockchain node 2 broadcasts tr46dqr for transaction 4 and wqa98op for transaction 6 to blockchain node 1.

[0104] like Figure 2EAs shown, when blockchain node 1 receives the transaction digest tr46dqr of transaction 4 to be uploaded to the blockchain and the transaction digest wqa98op of transaction 6 to be uploaded to the blockchain returned by blockchain node 2, it searches for the transactions to be uploaded to the blockchain corresponding to transaction digest tr46dqr and transaction digest wqa98op respectively in its own maintained transaction pool, extracts the transaction data of the found transactions to be uploaded to the blockchain, obtains the transaction data of transactions to be uploaded to the blockchain 4 and transactions to be uploaded to the blockchain 6 respectively, and broadcasts the transaction data of transactions to be uploaded to the blockchain 2 respectively, so as to broadcast only the transactions to be uploaded to the blockchain that the blockchain node has not received, reduce the duplicate broadcast of transactions to be uploaded to the blockchain and the resource overhead of transaction broadcasting, and improve the efficiency of transaction broadcasting.

[0105] The embodiments of this disclosure are described in general below.

[0106] According to one embodiment of this disclosure, a blockchain transaction processing method is provided.

[0107] This blockchain transaction processing method is generally applied in business scenarios where a large number of transactions to be uploaded to the blockchain need to be broadcast among various blockchain nodes, for example... Figures 2A-2E The example shown illustrates a transaction broadcasting scenario. This disclosure provides a transaction broadcasting scheme based on grouping and verifying transactions to be uploaded to the blockchain, which can improve transaction broadcasting efficiency while reducing the resource overhead of broadcasting transactions in the blockchain network.

[0108] This blockchain transaction processing method is executed by the first blockchain node in the blockchain network.

[0109] The first blockchain node refers to any blockchain node in the blockchain network.

[0110] like Figure 3 As shown, a blockchain transaction processing method according to an embodiment of this disclosure may include:

[0111] Step 310: Within the current broadcast period, based on the multiple pending transactions in the maintained first transaction pool, determine multiple candidate transaction groups;

[0112] Step 320: Based on the total number of transaction broadcasts of the first blockchain node, determine the target transaction group from multiple candidate transaction groups;

[0113] Step 330: Send the first transaction digests of each of the multiple transactions in the target transaction group to the second blockchain node in the blockchain network, so that the second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be put on the chain in the maintained second transaction pool and the first transaction digests of each of the multiple transactions, and returns the target transaction digest to the first blockchain node;

[0114] Step 340: Based on the target transaction digest received from the second blockchain node, extract the target transaction in the target transaction group whose first transaction digest matches the target transaction digest, and broadcast the transaction data of the target transaction to the second blockchain node.

[0115] Steps 310-340 are described in detail below.

[0116] In step 310, within the current broadcast period, multiple candidate transaction groups are determined based on multiple transactions to be added to the chain in the maintained first transaction pool.

[0117] The current broadcast period refers to a time interval within which the first blockchain node in the blockchain network, as well as other blockchain nodes besides the first blockchain node, can send the transactions to be uploaded to the blockchain that they have received from the object terminal to other blockchain nodes.

[0118] It should be noted that the broadcast cycles in this embodiment are closely connected and continuous, and the duration of each broadcast cycle can be fixed or dynamically changing.

[0119] The first transaction pool refers to the transaction pool maintained locally by the first blockchain node. The first transaction pool is used to record the transactions to be uploaded to the chain that the first blockchain node receives from the object terminal or from other blockchain nodes.

[0120] Transactions pending on the blockchain refer to data submitted by an object terminal to the blockchain network that needs to be recorded on the blockchain. Transactions pending on the blockchain can often indicate specific content related to resource interaction, or specific content related to information verification, etc.

[0121] Candidate transaction groups refer to groups of transactions that have the opportunity to be broadcast on the blockchain during the current broadcast cycle.

[0122] In the specific implementation of this embodiment, within the current broadcast period, the first blockchain node can first determine the total number of candidate transaction groups to be generated; then, the multiple transactions to be uploaded to the chain in the maintained first transaction pool are randomly grouped to obtain multiple candidate transaction groups.

[0123] Furthermore, to control the number of transactions to be added to the blockchain within each candidate transaction group, it is not necessary to include all transactions to be added to the blockchain within the group. Specifically, transactions to be added to the blockchain are first extracted from the first transaction pool, and then these extracted transactions are grouped to obtain multiple candidate transaction groups. In this way, only the extracted transactions to be added to the blockchain are grouped, and the transactions to be added to the blockchain that have not yet been extracted are not processed for the time being.

[0124] To save space, the specific implementation process of determining multiple candidate transaction groups based on multiple transactions to be uploaded to the chain in the first transaction pool, as described in this embodiment of the disclosure, will be described in detail below. It will not be repeated here.

[0125] In step 320, the target transaction group is determined from multiple candidate transaction groups based on the total number of transaction broadcasts of the first blockchain node.

[0126] The total number of transaction broadcasts indicates the number of transaction broadcasts performed by the first blockchain node before the current time. Since the broadcasting of transaction data for on-chain transactions by the first blockchain node within a broadcast cycle is often considered as one transaction broadcast, the total number of transaction broadcasts can also be seen as the number of broadcast cycles that have elapsed since the blockchain network's initialization until the current broadcast cycle.

[0127] The target transaction group refers to the group consisting of transactions that need to be broadcast on the chain within the current broadcast cycle.

[0128] In the specific implementation of this embodiment, firstly, the total number of candidate transaction groups is determined, and the group number of each candidate transaction group is determined; then, the quotient of the total number of transaction broadcasts divided by the total number is rounded up to obtain an integer value. Further, the candidate transaction group whose group number matches the integer value is selected as the target transaction group.

[0129] To save space, the specific implementation process of determining the target transaction group from multiple candidate transaction groups based on the total number of transaction broadcasts in this embodiment will be described in detail below. It will not be repeated here.

[0130] In step 330, the first transaction digests of each of the multiple transactions in the target transaction group are sent to the second blockchain node in the blockchain network, so that the second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be put on the chain in the maintained second transaction pool and the first transaction digests of each of the multiple transactions, and returns the target transaction digest to the first blockchain node.

[0131] The first transaction summary is used to indicate the result of the first blockchain node's summary operation on each transaction to be added to the chain in the target transaction group.

[0132] A second blockchain node refers to any blockchain node in a blockchain network that is distinct from the first blockchain node.

[0133] The second transaction pool refers to the transaction pool maintained locally by the second blockchain node. The second transaction pool is used to record the transactions to be uploaded to the chain that the second blockchain node receives from the object terminal or from other blockchain nodes.

[0134] The second transaction summary is used to indicate the result of the summary operation performed by the second blockchain node on each transaction to be uploaded to the chain in the second transaction pool.

[0135] The target transaction summary refers to the first transaction summary, which is different from the second transaction summary.

[0136] It should be noted that the first transaction digest, the second transaction digest, and the target transaction digest have the same string length, and each blockchain node in the blockchain network uses the same digest algorithm when performing digest calculations on the transactions to be uploaded to the chain in its locally maintained transaction pool.

[0137] In this specific implementation, firstly, the first blockchain node performs a digest operation on the transaction data of each transaction in the target transaction group to obtain a first transaction digest corresponding to each transaction in the target transaction group. Next, the first transaction digests of each transaction in the target transaction group are sent to other blockchain nodes in the blockchain network besides the first blockchain node (e.g., a second blockchain node). At this time, the second blockchain node receives multiple first transaction digests sent by the first blockchain node. Based on this, the second blockchain node uses the same digest algorithm as the first blockchain node to perform a digest operation on the transaction data of each transaction to be added to the blockchain in its locally maintained second transaction pool to obtain a second transaction digest corresponding to each transaction to be added to the blockchain. Further, if the second transaction digest is the same as the first transaction digest, then the second transaction digest and the transaction to be added to the blockchain pointed to by the first transaction digest are the same. Therefore, the second blockchain node compares the second transaction digests of each of the multiple transactions to be added to the blockchain with the first transaction digests of each of the multiple transactions, finds the first transaction digest that is different from the second transaction digest as the target transaction digest, and sends the target transaction digest back to the first blockchain node.

[0138] To save space, the specific implementation process of the second blockchain node determining the target transaction digest in this embodiment of the disclosure will be described in detail below. It will not be repeated here.

[0139] In step 340, based on the target transaction digest received from the second blockchain node, the target transaction whose first transaction digest matches the target transaction digest is extracted from the target transaction group, and the transaction data of the target transaction is broadcast to the second blockchain node.

[0140] The target transaction refers to the pending transaction that the first blockchain node wants to broadcast to the second blockchain node within the current broadcast week.

[0141] In this specific implementation, when the first blockchain node receives a target transaction digest from the second blockchain node, it indicates that the second blockchain node's second transaction pool does not contain a transaction to be added to the blockchain corresponding to the target transaction digest. The first blockchain node then needs to broadcast this type of transaction to the second blockchain node. Based on this, the first blockchain node first extracts target transactions from the target transaction group whose first transaction digest matches the target transaction digest. These target transactions are those that have transactions to be added to the blockchain in the first transaction pool but not in the second transaction pool. Next, the first blockchain node broadcasts the transaction data of the target transaction to the second blockchain node, so that the second blockchain node stores the transaction data of the target transaction in its own maintained second transaction pool.

[0142] Through steps 310-340 above, this embodiment of the disclosure, taking into account the amount of data that the network bandwidth of the blockchain network allows to transmit, provides a method for periodically broadcasting transactions to be uploaded to the blockchain in groups. Specifically, when the first blockchain node broadcasts a transaction, within the current broadcast period, the first blockchain node first divides the multiple transactions to be uploaded to the blockchain in its maintained first transaction pool into multiple candidate transaction groups, so that each candidate transaction group contains only a portion of the transactions to be uploaded to the blockchain; then, based on the total number of transaction broadcasts by the first blockchain node, the target transaction group is determined from the multiple candidate transaction groups. In this way, only the transactions to be uploaded to the blockchain in the target transaction group are broadcast in the current broadcast period, which can reduce the node load. Further, in this embodiment of the disclosure, the transactions to be uploaded to the blockchain in the target transaction group are not broadcast directly. Instead, the first transaction digests of each of the multiple transactions in the target transaction group are first sent to the second blockchain node in the blockchain network, so that the second blockchain node can query which transactions to be uploaded to the blockchain are missing in its maintained second transaction pool based on the first transaction digests, and return the first transaction digests corresponding to these missing transactions to be uploaded to the blockchain as the target transaction digests. In this way, the first blockchain node only needs to broadcast the transaction data of the target transaction corresponding to the target transaction digest to the second blockchain node, instead of broadcasting all transactions to be uploaded to the blockchain in the target transaction group. This approach effectively reduces the duplicate broadcasting of transactions to be uploaded to the blockchain, broadcasting only the portion of transactions to be uploaded to the blockchain that differ in the transaction pools of each blockchain node. This reduces the resource overhead of broadcasting transactions in the blockchain network while improving the efficiency of transaction broadcasting.

[0143] The above is a general description of steps 310-340. The following will provide a detailed description of the specific implementation of steps 310-340.

[0144] Step 310 will be described in detail below.

[0145] In step 310, within the current broadcast period, multiple candidate transaction groups are determined based on multiple transactions to be added to the chain in the maintained first transaction pool.

[0146] Please refer to Figure 4 In one embodiment, step 310 specifically includes, but is not limited to, the following steps 410-420:

[0147] Step 410: Extract a first number of transactions to be added to the chain as candidate transactions from the first transaction pool;

[0148] Step 420: Based on the first number and the maximum number of transactions within the candidate transaction group, group the candidate transactions to obtain multiple candidate transaction groups, so that the total number of candidate transactions in each candidate transaction group is not greater than the maximum number of transactions within the group.

[0149] Steps 410-420 are described in detail below.

[0150] In step 410, the first number is used to indicate the total number of transactions to be included in the transaction broadcast scope during the current broadcast period. The first number is less than the total number of transactions to be included in the first transaction pool.

[0151] Candidate transactions refer to transactions that are to be included in the transaction broadcasting scope during the current broadcasting cycle and are yet to be added to the blockchain.

[0152] In the specific implementation of this embodiment, a first number of transactions to be uploaded to the blockchain can be randomly selected from the first transaction pool and extracted, and the extracted first number of transactions to be uploaded to the blockchain can be used as candidate transactions.

[0153] In step 420, the maximum number of transactions within a group is used to indicate the upper limit of candidate transactions that can be accommodated in a candidate transaction group.

[0154] To save space, the specific implementation process of grouping candidate transactions into multiple candidate transaction groups according to the embodiments of this disclosure will be described in detail below. It will not be repeated here.

[0155] The advantage of this embodiment is that, considering the large number of transactions to be uploaded to the chain in the first transaction pool, in the current broadcast cycle, only a first number of transactions to be uploaded to the chain are extracted from the first transaction pool as candidate transactions for grouping and processing. This can effectively control the number of transactions to be uploaded to the chain to be broadcast in the current broadcast cycle and the number of candidate transactions included in each candidate transaction group. This can improve the rationality of transaction broadcasting and keep the resource consumption of transaction broadcasting within a controllable range, so that the data transmission volume of the blockchain network in each broadcast cycle remains relatively stable.

[0156] Please refer to Figure 5In one embodiment, step 410 specifically includes, but is not limited to, the following steps 510-520:

[0157] Step 510: In the first transaction pool, determine the on-chain resource overhead for each of the multiple transactions to be added to the chain;

[0158] Step 520: Select a first number of transactions to be added to the blockchain whose on-chain resource cost is greater than or equal to the first threshold as candidate transactions.

[0159] Steps 510-520 are described in detail below.

[0160] In step 510, the on-chain resource overhead is used to indicate the resources required to record the transaction to be on-chain onto the blockchain.

[0161] In the specific implementation of this embodiment, the process of determining the on-chain resource overhead of each of the multiple candidate transactions to be on-chain includes, but is not limited to, the following steps:

[0162] Obtain the overhead rate of the blockchain network and the transaction size of transactions to be added to the chain;

[0163] Calculate the on-chain resource overhead for transactions to be added to the blockchain based on transaction size and overhead rate.

[0164] The overhead rate indicates the amount of resources required to record a unit size of transaction data onto the blockchain. The transaction size indicates the total amount of data (transaction associated objects, transaction content, and reference resource status information, etc.) of the transaction to be uploaded to the blockchain. The transaction size can be quantified as the number of bytes of all transaction data to be uploaded, while the overhead rate indicates the amount of resources required to record a unit byte of data onto the blockchain.

[0165] Specifically, firstly, a request to obtain the overhead rate can be sent to a publicly trusted platform or blockchain network, and the overhead rate provided by the publicly trusted platform or blockchain network can be received. Next, the data volume of the transaction-related objects, transaction content, and reference resource status information of the transaction to be uploaded to the blockchain is statistically analyzed to obtain the total data volume of the transaction to be uploaded to the blockchain, and this total data volume is used as the transaction size of the transaction to be uploaded to the blockchain. Further, the transaction size is multiplied by the overhead rate to obtain the on-chain resource cost of the transaction to be uploaded to the blockchain.

[0166] In step 520, the first threshold is used to indicate the minimum on-chain resource cost of a transaction to be broadcast on the blockchain network.

[0167] In this specific implementation, for each transaction to be added to the blockchain, the on-chain resource cost of the transaction is compared with a first threshold. If the on-chain resource cost is greater than or equal to the first threshold, the transaction to be added to the blockchain is determined as an intermediate transaction. If the on-chain resource cost is less than the first threshold, the transaction to be added to the blockchain is not determined as an intermediate transaction. Finally, the intermediate transactions are sorted in descending order of on-chain resource cost, and the first number of intermediate transactions in the sorted list are determined as candidate transactions.

[0168] like Figure 8A As shown, the first blockchain node has four transactions awaiting on-chain processing. The on-chain resource cost for transaction 1 is 20, for transaction 2 it is 40, for transaction 3 it is 50, and for transaction 4 it is 80. Based on this, when the first threshold is 30, transactions 2, 3, and 4 are identified as candidate transactions.

[0169] The advantage of this embodiment is that it takes into account the different transaction sizes of each transaction to be uploaded to the blockchain, calculates the on-chain cost for each transaction, and obtains the on-chain resource cost for each transaction. This makes it easier to determine the resource benefits that the blockchain network can obtain by uploading each transaction to the blockchain. Furthermore, based on the different on-chain resource costs, transactions with higher on-chain resource costs are prioritized as candidate transactions, which improves the rationality of transaction processing.

[0170] Please refer to Figure 6 In one embodiment, step 410 specifically includes, but is not limited to, the following steps 610-620:

[0171] Step 610: In the first transaction pool, determine the time difference between the transaction timestamp and the current time for each of the multiple transactions to be added to the chain;

[0172] Step 620: Select the first number of transactions to be added to the chain with a time difference greater than or equal to the second threshold as candidate transactions.

[0173] Steps 610-620 are described in detail below.

[0174] In step 610, the transaction timestamp is used to indicate the time when each transaction to be added to the blockchain is sent to the blockchain network.

[0175] In the specific implementation of this embodiment, since the transaction timestamp of each transaction to be uploaded to the blockchain is carried when each transaction to be uploaded to the blockchain network, based on this, with authorization, the transaction information of each transaction to be uploaded to the blockchain can be extracted to obtain the transaction timestamp of each transaction to be uploaded to the blockchain.

[0176] Furthermore, since the blockchain network's server backend also records the time points when it receives transactions awaiting upload, it is possible, with authorization, to extract the time points when each transaction was received from the server backend logs to obtain the transaction timestamp for each transaction.

[0177] Furthermore, for each transaction to be added to the blockchain, the difference between the transaction timestamp and the current time is calculated, and the transaction timestamp is subtracted from the current time to obtain the time difference between the transaction timestamp and the current time of the transaction to be added to the blockchain.

[0178] In step 620, the second threshold is used to indicate the minimum difference between the transaction timestamp of a transaction to be broadcast on the blockchain network and the current time.

[0179] In this specific implementation, for each transaction to be added to the blockchain, the time difference between the transactions is compared with a second threshold. If the time difference is greater than or equal to the second threshold, the transaction to be added to the blockchain is determined as an intermediate transaction. If the time difference is less than the second threshold, the transaction to be added to the blockchain is not determined as an intermediate transaction. Finally, the intermediate transactions are sorted in descending order of time difference, and the first number of intermediate transactions in the sorted order are determined as candidate transactions.

[0180] like Figure 8B As shown, the first blockchain node has four transactions awaiting on-chain processing. Transaction 1 has a timestamp of 12:13, Transaction 2 has a timestamp of 13:54, Transaction 3 has a timestamp of 15:41, and Transaction 4 has a timestamp of 17:06. Based on this, at the current time of 18:00 and with the second threshold of 1 hour, Transaction 1, Transaction 2, and Transaction 3 are identified as candidate transactions.

[0181] The advantage of this embodiment is that it takes into account the different timestamps of each transaction to be uploaded to the blockchain, and prioritizes the transaction to be uploaded to the blockchain with an earlier timestamp (the transaction to be uploaded to the blockchain with a larger time difference between the transaction timestamp and the current time) as the candidate transaction for broadcasting, which can improve the efficiency and orderliness of transaction broadcasting in the blockchain network.

[0182] Please refer to Figure 7 In one embodiment, step 410 specifically includes, but is not limited to, the following steps 710-730:

[0183] Step 710: In the first transaction pool, determine the on-chain resource cost of each of the multiple transactions to be on-chain, and the time difference between the transaction timestamp of each of the multiple transactions to be on-chain and the current time;

[0184] Step 720: For each transaction to be uploaded to the blockchain, determine the transaction score based on the resource overhead and time difference for uploading to the blockchain.

[0185] Step 730: Select the first number of transactions to be added to the chain with a transaction score greater than or equal to the third threshold as candidate transactions.

[0186] Steps 710-730 are described in detail below.

[0187] In step 710, the specific process of determining the on-chain resource overhead for each of the multiple transactions to be added to the blockchain is similar to step 510 above; the specific process of determining the time difference between the transaction timestamp and the current time for each of the multiple transactions to be added to the blockchain is similar to step 610 above. To save space, these details will not be repeated.

[0188] In step 720, the transaction score is used to indicate the numerical quantification of the score by which the transaction to be added to the chain is selected as a candidate transaction.

[0189] In a specific implementation of this embodiment, step 720 may include, but is not limited to, the following steps:

[0190] Based on the on-chain resource overhead, determine the first transaction sub-score of the transaction to be on-chain;

[0191] Based on the transaction timestamp, determine the second transaction sub-score of the transaction to be added to the chain;

[0192] The transaction score of the transaction to be added to the chain is determined based on the first transaction sub-score and the second transaction sub-score.

[0193] The first transaction sub-score indicates the priority of transactions to be added to the blockchain in terms of resource overhead. A higher first transaction sub-score indicates a higher priority for the transaction to be added to the blockchain. The second transaction sub-score indicates the priority of transactions to be added to the blockchain in terms of transaction timestamp. A higher second transaction sub-score indicates a higher priority for the transaction to be added to the blockchain.

[0194] Specifically, firstly, a preset function is obtained, then the on-chain resource overhead is input into the preset function, and the output of the preset function is used as the first transaction sub-score. The preset function is an increasing function with on-chain resource overhead as the independent variable and the first transaction sub-score as the dependent variable. The larger the on-chain resource overhead of the transaction to be added to the chain, the larger the first transaction sub-score. Simultaneously, for each transaction to be added to the chain, based on the interval of the time difference in a preset mapping table, the candidate score corresponding to the block where the time difference lies is used as the second transaction sub-score. The preset mapping table is used to indicate the candidate scores corresponding to each time difference interval. The larger the time difference between the transaction timestamp and the current time, the larger the second transaction sub-score. Further, a first weight and a second weight are determined. The first weight indicates the importance of on-chain resource overhead in screening candidate transactions, and the second weight indicates the importance of the transaction timestamp in screening candidate transactions. Finally, the product of the first weight and the first transaction sub-score, and the product of the second weight and the second transaction sub-score are added together to obtain the transaction score.

[0195] In step 730, the third threshold is used to indicate the minimum transaction score that a transaction to be added to the chain must meet when it is selected as a candidate transaction.

[0196] In this specific implementation, for each transaction to be added to the blockchain, its transaction score is compared with a third threshold. If the transaction score is greater than or equal to the third threshold, the transaction to be added to the blockchain is determined as an intermediate transaction. If the transaction score is less than the third threshold, the transaction to be added to the blockchain is not determined as an intermediate transaction. Finally, the intermediate transactions are sorted in descending order of their transaction scores, and the top 100 intermediate transactions in the sorted list are determined as candidate transactions.

[0197] It should be noted that when the transaction score is greater than or the number of transactions to be added to the chain is less than the first number, the transactions to be added to the chain are directly sorted in descending order of transaction score, and the first number of transactions to be added to the chain in the sorted order are determined as candidate transactions.

[0198] like Figure 8A The diagram illustrates how the first transaction sub-score is determined based on the on-chain resource cost of the transactions to be added to the blockchain. Specifically, the second transaction sub-score for transaction 1, with an on-chain resource cost of 20, is 60; the transaction sub-score for transaction 2, with an on-chain resource cost of 40, is 70; the transaction sub-score for transaction 3, with an on-chain resource cost of 50, is 75; and the transaction sub-score for transaction 4, with an on-chain resource cost of 80, is 90.

[0199] like Figure 8BThe diagram illustrates how the second transaction sub-score is determined based on the transaction timestamps of the transactions to be added to the blockchain. Specifically, the second transaction sub-score for transaction 1 (transaction timestamp 12:13) is 86; the second transaction sub-score for transaction 2 (transaction timestamp 13:54) is 78; the second transaction sub-score for transaction 3 (transaction timestamp 15:41) is 70; and the second transaction sub-score for transaction 4 (transaction timestamp 17:06) is 62.

[0200] like Figure 8C The diagram illustrates the selection of candidate transactions based on the first and second transaction sub-scores. Specifically, when both the first and second weights are 0.5, the transaction score of transaction 1 (with a first transaction sub-score of 86 and a second transaction sub-score of 60) is 73; the transaction score of transaction 2 (with a first transaction sub-score of 78 and a second transaction sub-score of 70) is 74; the transaction score of transaction 3 (with a first transaction sub-score of 70 and a second transaction sub-score of 75) is 72.5; and the transaction score of transaction 4 (with a first transaction sub-score of 62 and a second transaction sub-score of 90) is 76. Therefore, when the first number is three, transactions 4, 2, and 1 are selected as candidate transactions.

[0201] The advantage of this embodiment is that when screening candidate transactions among multiple transactions to be added to the blockchain, both transaction timestamps and on-chain resource overhead are considered. Based on the calculation of scores and weighted calculations, transactions with earlier timestamps and higher on-chain resource overhead can be prioritized as candidate transactions for grouping and broadcasting, which can improve the rationality of transaction screening and thus improve the rationality of transaction broadcasting.

[0202] Please refer to Figure 9 In one embodiment, step 420 specifically includes, but is not limited to, the following steps 910-920:

[0203] Step 910: Determine the number of groups for multiple candidate transaction groups based on the quotient of the first number and the maximum number of transactions within the group;

[0204] Step 920: Based on the number of groups, assign candidate transactions to candidate transaction groups, so that each candidate transaction is assigned to a candidate transaction group.

[0205] Steps 910-920 are described in detail below.

[0206] In step 910, the number of groups is used to indicate the total number of candidate transaction groups.

[0207] In this specific implementation, firstly, a division operation is performed between the first number and the maximum number of transactions within the group. The first number is divided by the maximum number of transactions within the group to obtain the quotient. Next, the quotient is rounded up to the nearest integer, and this integer value is used as the group number for the multiple candidate transaction groups. This group number is greater than or equal to the quotient of the first number and the maximum number of transactions within the group.

[0208] The number of candidate transaction groups can be expressed as follows:

[0209]

[0210] Where K is the number of groups, and K is an integer greater than 0. MaxBatch refers to the maximum number of transactions within a group, and N is the first number. MaxBatch is a positive integer not greater than N, and N is a positive integer not less than K.

[0211] In step 920, firstly, based on the number of groups, a number of transaction groups are initialized to be empty. Next, each candidate transaction is randomly assigned to one of the number of empty transaction groups, and the total number of candidate transactions filled in each initially empty transaction group is not greater than the maximum number of transactions in the group, so that all candidate transactions are assigned to transaction groups, and the transaction group filled with at least one candidate transaction is designated as a candidate transaction group.

[0212] like Figure 10 As shown, when constructing candidate transaction groups, 13 candidate transactions were extracted from the first transaction pool, namely candidate transaction 1, candidate transaction 2, candidate transaction 3, candidate transaction 4, candidate transaction 5, candidate transaction 6, candidate transaction 7, candidate transaction 8, candidate transaction 9, candidate transaction 10, candidate transaction 11, candidate transaction 12, and candidate transaction 13. Then, when the maximum number of transactions within a candidate transaction group is 3, 13 is divided by 3 and rounded up, resulting in 5 groups. Based on this, the 13 candidate transactions are randomly divided into 5 groups, resulting in 5 candidate transaction groups. The first candidate transaction group includes candidate transaction 1 and candidate transaction 4; the second candidate transaction group includes candidate transaction 7, candidate transaction 3, and candidate transaction 2; the third candidate transaction group includes candidate transaction 5, candidate transaction 10, and candidate transaction 8; the fourth candidate transaction group includes candidate transaction 6, candidate transaction 11, and candidate transaction 9; and the fifth candidate transaction group includes candidate transaction 12 and candidate transaction 13.

[0213] The advantage of this embodiment is that the number of groups is determined based on the quotient of the first number and the maximum number of transactions within the group, which ensures that the total number of candidate transactions assigned to each candidate transaction group does not exceed the preset maximum number of transactions within the group. At the same time, a random allocation method is adopted for each candidate transaction, which can improve the flexibility and freedom of transaction grouping to a certain extent.

[0214] Randomly grouping candidate transactions introduces significant uncertainty into the candidate transactions assigned to each group. Therefore, this disclosure provides a scheme based on sequentially grouping candidate transactions, which improves the orderliness of transaction grouping.

[0215] Please refer to Figure 11 In one embodiment, step 920 specifically includes, but is not limited to, the following steps 1110-1130:

[0216] Step 1110: Sort the candidate transactions to obtain the transaction order;

[0217] Step 1120: Initialize the anchor transaction group as the first candidate transaction group among multiple candidate transaction groups;

[0218] Step 1130: Based on the transaction order, fill the unallocated candidate transactions into the anchor transaction group in sequence until the total number of candidate transactions in the anchor transaction group is equal to the maximum number of transactions in the group. Update the anchor transaction group with the next candidate transaction group of the anchor transaction group, and return to the step of filling the unallocated candidate transactions into the anchor transaction group in sequence based on the transaction order until all candidate transactions are allocated.

[0219] Steps 1110-1130 are described in detail below.

[0220] In step 1110, the transaction order is used to indicate the order in which the candidate transactions are grouped.

[0221] In the specific implementation of this embodiment, the candidate transactions can be sorted in descending order of their on-chain resource overhead to obtain the transaction order; alternatively, the candidate transactions can be sorted in descending order of their time difference between their transaction timestamps and the current time to obtain the transaction order.

[0222] In step 1120, the anchor transaction group refers to a candidate transaction group to which the candidate transaction is to be assigned.

[0223] In this specific implementation, since each of the multiple candidate transaction groups corresponds to a grouping index, the order of each candidate transaction group among the multiple candidate transaction groups can first be determined based on the grouping index. Next, the anchor transaction group is initialized as the first candidate transaction group among the multiple candidate transaction groups. For example, if the first blockchain node determines four candidate transaction groups, and the grouping indices of the four candidate transaction groups are set as A1, A2, A3, and A4 respectively, then the candidate transaction group with grouping index A1 is used as the anchor transaction group.

[0224] In step 1130, firstly, based on the transaction order, the first candidate transaction is filled into the anchor transaction group. Then, the second candidate transaction in the transaction order is filled into the anchor transaction group, and so on, until the total number of candidate transactions in the anchor transaction group equals the maximum number of transactions within the group, indicating that the first candidate transaction group has been constructed. Further, the anchor transaction group is updated with the next candidate transaction group to fill the second candidate transaction group. At this point, the process returns to the step of filling the anchor transaction group with unassigned candidate transactions based on the transaction order. The process continues, filling the first unassigned candidate transaction into the anchor transaction group according to the transaction order, and so on, until the total number of candidate transactions in the anchor transaction group equals the maximum number of transactions within the group. Only when all candidate transactions are assigned to a single candidate transaction group is the grouping of candidate transactions considered complete.

[0225] The advantage of this embodiment is that it sets the order in which candidate transactions are grouped and processed. When grouping candidate transactions, each candidate transaction group is filled in sequentially. The next candidate transaction group is only filled when the number of candidate transactions in the previous candidate transaction group reaches the maximum number of transactions in the group, which can improve the orderliness of transaction grouping.

[0226] Since the resource gains that different blockchain nodes in a blockchain network can obtain by broadcasting different transactions to be uploaded to the chain are often different, this disclosure provides a scheme for sorting candidate transactions based on resource gains to take into account the broadcasting benefits of nodes, thereby improving the flexibility of transaction sorting.

[0227] Please refer to Figure 12 In one embodiment, step 1110 specifically includes, but is not limited to, the following steps 1210-1220:

[0228] Step 1210: For each candidate transaction, determine the resource gain that the first blockchain node can obtain on the candidate transaction;

[0229] Step 1220: Based on resource gain, sort the candidate transactions to obtain the transaction order.

[0230] Steps 1210-1220 are described in detail below.

[0231] In step 1210, the resource gain is used to indicate the incremental resources that the first blockchain node can obtain by processing the candidate transaction.

[0232] In the specific implementation of this embodiment, firstly, for each candidate transaction, the overhead gain and block reward that the first blockchain node can obtain by packaging and uploading the candidate transaction to the chain are obtained. Next, a weighted calculation is performed on the resource gain and block reward to obtain the resource gain that the first blockchain node can obtain on the candidate transaction.

[0233] Among them, overhead gain refers to the amount of resources provided to the first blockchain node by the object that submits the candidate transaction to the blockchain network when the first blockchain node is processing the candidate transaction; block reward refers to the resource reward that the first blockchain node will receive for successfully packaging and putting the candidate transaction on the chain.

[0234] In step 1220, based on resource gain, the candidate transactions are sorted from largest to smallest to obtain the transaction order. Specifically, candidate transactions with larger resource gains are ranked earlier in the transaction order, while candidate transactions with smaller resource gains are ranked later.

[0235] The advantage of this embodiment is that sorting candidate transactions based on resource gain allows multiple candidate transactions to be arranged in descending order of resource gain, thus improving the flexibility of transaction sorting. Simultaneously, grouping each candidate transaction sequentially under the resource gain-based transaction order ensures that multiple candidate transactions with larger resource gains are more closely grouped into the same candidate transaction group, thereby reducing the difference in resource gain among multiple candidate transactions within the same candidate transaction group.

[0236] The following is combined Figure 13A and Figure 13B An example is given to describe the specific process of grouping multiple candidate transactions.

[0237] like Figure 13AAs shown, for the 13 candidate transactions extracted by the first blockchain node from the first transaction pool, the transaction gain of candidate transaction 1 is 86; the transaction gain of candidate transaction 2 is 78; the transaction gain of candidate transaction 3 is 70; the transaction gain of candidate transaction 4 is 62; the transaction gain of candidate transaction 5 is 73; the transaction gain of candidate transaction 6 is 87; the transaction gain of candidate transaction 7 is 63; the transaction gain of candidate transaction 8 is 56; the transaction gain of candidate transaction 9 is 74; the transaction gain of candidate transaction 10 is 71; the transaction gain of candidate transaction 11 is 81; the transaction gain of candidate transaction 12 is 67; and the transaction gain of candidate transaction 13 is 51. Based on this, the candidate transactions are sorted in descending order of transaction gain, resulting in the transaction order [candidate transaction 6, candidate transaction 1, candidate transaction 11, candidate transaction 2, candidate transaction 9, candidate transaction 5, candidate transaction 10, candidate transaction 3, candidate transaction 12, candidate transaction 7, candidate transaction 4, candidate transaction 8, candidate transaction 13].

[0238] like Figure 13B As shown, when assigning 13 candidate transactions to 5 different candidate transaction groups, candidate transactions 6, 1, and 11 are first assigned to candidate transaction group 1; then candidate transactions 2, 9, and 5 are assigned to candidate transaction group 2. Next, candidate transactions 10, 3, and 12 are assigned to candidate transaction group 3, and candidate transactions 7, 4, and 8 are assigned to candidate transaction group 4. Finally, candidate transaction 13 is assigned to candidate transaction group 5.

[0239] Because the performance of individual blockchain nodes in a blockchain network often varies, nodes with poor performance are often unable to transmit a large amount of transaction information to other blockchain nodes in a single data transmission, while nodes with good performance can often transmit a large amount of data to other blockchain nodes in a single data transmission. Based on this, this disclosure provides a scheme for determining the maximum number of transactions allowed for each blockchain node in a transaction group based on node performance, which can improve the accuracy and rationality of setting the maximum number of transactions in a transaction group.

[0240] Please refer to Figure 14 In one embodiment, the maximum number of transactions within a candidate transaction group is determined in the following manner:

[0241] Step 1410: Determine the operating status parameters and load status parameters of the first blockchain node in the previous broadcast cycle of the current broadcast cycle;

[0242] Step 1420: Determine the node performance score of the first blockchain node based on the running status parameters and load status parameters;

[0243] Step 1430: Determine the maximum number of transactions within a group based on the node performance score.

[0244] Steps 1410-1430 are described in detail below.

[0245] In step 1410, the running status parameter is used to indicate the node running status of the first blockchain node in the previous broadcast cycle of the current broadcast cycle. The load status parameter is used to indicate the load situation of the first blockchain node during normal operation in the previous broadcast cycle of the current broadcast cycle.

[0246] The previous broadcast cycle of the current broadcast cycle refers to the broadcast cycle that precedes and immediately follows the current broadcast cycle.

[0247] In this specific implementation, the log file of the first blockchain node contains a large amount of operational and load status information. Therefore, with authorization, the operational and load status parameters of the first blockchain node in the previous broadcast cycle can be determined by extracting and analyzing the log file. For example, the connection status of the first blockchain node can be determined by examining the "connected" information in its log file.

[0248] In step 1420, the node performance score is used to quantify the performance of the first blockchain node from a statistical perspective.

[0249] To save space, the specific process of determining the node performance score of the first blockchain node based on the running status parameters and load status parameters in this embodiment of the present disclosure will be described in detail below, and will not be repeated here.

[0250] In step 1430, firstly, the number mapping table between node performance scores and maximum transaction count is invoked. This number mapping table indicates the maximum transaction count corresponding to each node performance score interval. Next, based on the node performance score interval of the first blockchain node in the number mapping table, the maximum transaction count corresponding to that interval is taken as the maximum transaction count within the group.

[0251] The advantage of this embodiment is that it addresses the drawback of setting a fixed maximum number of transactions per group for all blockchain nodes in a blockchain network, which leads to inefficient transaction processing. Instead, for each blockchain node, a performance score is determined by combining the allowed state and load state of the first blockchain node in the previous broadcast cycle. The maximum number of transactions per group is then set based solely on this performance score for the first blockchain node. This approach improves the accuracy and rationality of setting the maximum number of transactions per group, while ensuring that the maximum number of transactions allowed for each blockchain node within a transaction group is determined based on node performance.

[0252] In this embodiment of the disclosure, the operating status parameters include the data transmission rate and packet loss rate of the first blockchain node in the previous broadcast cycle, and the load status parameters include the CPU utilization, memory utilization and bandwidth utilization of the first blockchain node in the previous broadcast cycle.

[0253] Please refer to Figure 15 In one embodiment, step 1420 specifically includes, but is not limited to, the following steps 1510-1530:

[0254] Step 1510: Determine the first score based on the data transmission rate and packet loss rate;

[0255] Step 1520: Determine the second score based on CPU utilization, memory utilization, and bandwidth utilization;

[0256] Step 1530: Determine the node performance score based on the first score and the second score.

[0257] Steps 1510-1530 are described in detail below.

[0258] In step 1510, the first score is used to indicate the specific circumstances of the performance rating of the first blockchain node based on the data transmission rate and packet loss rate.

[0259] In the specific implementation of this embodiment, the process of step 1510 is similar to that of step 720 described above. To save space, it will not be described again.

[0260] In step 1520, the second score is used to indicate the specific details of the performance rating of the first blockchain node based on CPU utilization, memory utilization, and bandwidth utilization.

[0261] In the specific implementation of this embodiment, the process of step 1510 is similar to that of step 720 described above. To save space, it will not be described again.

[0262] In step 1530, the specific process of determining the node performance score based on the first score and the second score is similar to the specific process of determining the transaction score based on the first transaction sub-score and the second transaction sub-score in step 720 above. To save space, it will not be described again.

[0263] The advantage of this embodiment is that, when determining the node performance score of the first blockchain node based on operating status parameters and load status parameters, it considers that both operating status parameters and load status parameters involve multiple indicators. Multiple dimensions of indicators are introduced for both operating status parameters and load status parameters to jointly determine the first score corresponding to the operating status parameters and the second score corresponding to the load status parameters. This improves the accuracy of score calculation for operating status parameters and load status parameters in determining the node performance score. Furthermore, determining the node performance score based on the first score and the second score further improves the accuracy of scoring the node performance of the first blockchain node.

[0264] Randomly setting the broadcast cycle duration of a blockchain network and keeping it fixed leads to poor flexibility in transaction broadcasting, which is detrimental to improving the efficiency of blockchain transaction broadcasting. Therefore, this disclosure provides a scheme for setting the broadcast cycle duration based on the network bandwidth and network structure of the blockchain network, which can improve the accuracy and flexibility of determining the cycle duration.

[0265] Please refer to Figure 16 In one embodiment, the duration of the current broadcast period is determined in the following way:

[0266] Step 1610: Determine the network bandwidth and network structure of the blockchain network;

[0267] Step 1620: Determine the network score of the blockchain network based on network bandwidth and network structure;

[0268] Step 1630: Determine the cycle duration based on the network score.

[0269] Steps 1610-1630 are described in detail below.

[0270] In step 1610, network bandwidth is used to indicate the number of transactions per second of the blockchain network; network structure refers to the specific topology of the blockchain network, which is used to indicate the total number of blockchain nodes contained in the blockchain network and the connection relationships between the blockchain nodes.

[0271] In the specific implementation of this embodiment, when determining the network bandwidth of the blockchain network, performance testing tools (e.g., Hyperledger Capability, etc.) can be used to measure the network bandwidth of the blockchain network.

[0272] Furthermore, when determining the network structure of a blockchain network, firstly, the total number of blockchain nodes and the connection relationships between them are determined. Then, based on the total number of blockchain nodes and their connection relationships, a search is conducted among multiple reference network structures. The reference network structure that matches the connection relationships of the blockchain nodes in the current blockchain network is determined as the final network structure. These reference network structures often include three categories: centralized networks, decentralized networks, and decentralized networks.

[0273] In step 1620, the network score is used to indicate the overall network performance of the blockchain network from a statistical perspective.

[0274] Specifically, the process of determining the network score of a blockchain network based on network bandwidth and network structure may include, but is not limited to, the following steps:

[0275] Determine the first network sub-score based on network bandwidth;

[0276] Based on the network structure, determine the second network sub-score;

[0277] The network score of the blockchain network is determined based on the first network sub-score and the second network sub-score.

[0278] In this specific implementation, the process of determining the first network sub-score based on network bandwidth in step 1620 is similar to the process of determining the first transaction sub-score of the transaction to be uploaded to the blockchain based on on-chain resource overhead in step 720. The process of determining the second network sub-score based on network structure in step 1620 is similar to the process of determining the second transaction sub-score of the transaction to be uploaded to the blockchain based on transaction timestamps in step 720. The process of determining the network score of the blockchain network based on the first and second network sub-scores in step 1620 is similar to the process of determining the transaction score of the transaction to be uploaded to the blockchain based on the first and second transaction sub-scores in step 720. For the sake of brevity, these details will not be elaborated further.

[0279] In step 1630, a preset function is first obtained, then the network score is input into the preset function, and the output of the preset function is used as the period duration. The preset function is an increasing function with the network score as the independent variable and the period duration as the dependent variable. The larger the network score, the longer the broadcast period of the blockchain network.

[0280] It should be noted that the preset function in step 1630 is different from the preset function in step 720. For the sake of distinction, the preset function in step 720 can be regarded as the first function, and the preset function in step 1630 can be regarded as the second function.

[0281] The advantage of this embodiment is that it enables dynamic adjustment and updating of the cycle length of each broadcast cycle based on the network bandwidth and network structure of the blockchain network, so that the length of the broadcast cycle is related to the network bandwidth and network structure. This approach can improve the rationality and accuracy of setting the cycle length of the broadcast cycle.

[0282] Step 320 will be described in detail below.

[0283] In step 320, the target transaction group is determined from multiple candidate transaction groups based on the total number of transaction broadcasts of the first blockchain node.

[0284] Please refer to Figure 17 In one embodiment, step 320 specifically includes, but is not limited to, the following steps 1710-1730:

[0285] Step 1710: Determine the number of candidate transaction groups and the group index of each candidate transaction group;

[0286] Step 1720: Perform a modulo operation based on the number of groups and the total number of transaction broadcasts to obtain the target remainder;

[0287] Step 1730: Determine the target transaction group from multiple candidate transaction groups based on the target remainder and grouping index.

[0288] Steps 1710-1730 are described in detail below.

[0289] In step 1710, the grouping index is used to uniquely identify each candidate transaction group in order to distinguish each candidate transaction group from other candidate transaction groups.

[0290] In the specific implementation of this embodiment, the process of determining the number of groups for multiple candidate transaction groups is similar to step 910 described above. To save space, it will not be repeated here.

[0291] Furthermore, when determining the grouping index for multiple candidate transaction groups, the grouping index for each candidate transaction group can be unified into numbers, letters, or a combination of numbers and letters. When determining the grouping index, the numbers or letters in the grouping index of each candidate transaction group are set to be different to distinguish between different candidate transaction groups.

[0292] In a specific example, for multiple candidate transaction groups, the group index format is determined to be the same letter followed by a number that increments sequentially from 1. For example, the group index of the first candidate transaction group is A1, the group index of the second candidate transaction group is A2, and so on.

[0293] In step 1720, firstly, the total number of transaction broadcasts is converted into a byte array, and the total number of transaction broadcasts is converted from integer form to binary form to obtain a target byte. The size of the target byte generally does not exceed 256. Next, a modulo operation is performed on the target byte and the number of groups, and the target byte is divided by the number of groups to obtain the target remainder.

[0294] In addition, when performing modulo operations based on the number of groups and the total number of transaction broadcasts, the total number of transaction broadcasts can be hashed using a hash function to convert it into a digest value. Then, the digest value is used to perform a modulo operation with the number of groups, and the digest value is divided by the number of groups to obtain the target remainder.

[0295] In step 1730, since the modulo operation is based on the number of groups, the target remainder is a positive integer no greater than the number of groups. Based on this, before determining the target transaction group, a one-to-one correspondence can be established between the target remainders of different values ​​and the grouping indices of each candidate transaction group. Thus, in the actual modulo operation, based on the specific value of the target remainder and this correspondence, the grouping index corresponding to that specific value is found, and the found grouping index is determined as the grouping index of the target transaction group, thereby identifying the target transaction group from multiple candidate transaction groups.

[0296] like Figure 18 The diagram illustrates a specific implementation process for determining the target transaction group. Specifically, first, the total number of transaction broadcasts (2 times) is converted into a byte array, resulting in byte 0 being 01101. Further, a modulo operation is performed using the number of groups (4), yielding a target remainder of 2. Assuming the target remainder perfectly matches the group index of each candidate transaction group, the candidate transaction group with group index 2 is searched, and candidate transaction group 2 is determined as the target transaction group.

[0297] In a specific example, each blockchain node in the blockchain network sets an auto-incrementing timer for each broadcast cycle. Since each blockchain node has one opportunity per broadcast cycle to broadcast transaction data from its maintained transaction pool of transactions awaiting on-chain to other blockchain nodes, the timer is incremented by 1 from 0 in each broadcast cycle. Based on this, the total number of times the blockchain node has broadcast transaction data for transactions awaiting on-chain (total number of transaction broadcasts) can be counted using the timer within the current broadcast cycle. When the various values ​​of the target remainder are completely consistent with the various group indices, the group index of the target transaction group to be broadcast in the current broadcast cycle can be expressed as follows:

[0298] Index = BroadcastCnt%K;

[0299] Where K refers to the number of groups, Index refers to the group index of the target transaction group, % refers to the modulo operation, and BroadcastCnt refers to the timer.

[0300] The advantage of this embodiment is that by performing a modulo operation using the number of groups and the total number of transaction broadcasts to obtain the target remainder, and by utilizing the mapping relationship between various values ​​of the target remainder and the group index of the candidate transaction groups, the convenience and accuracy of determining the target transaction group can be effectively improved.

[0301] Steps 330-340 are described in detail below.

[0302] In steps 330-340, the first transaction digests of each of the multiple transactions in the target transaction group are sent to the second blockchain node in the blockchain network, so that the second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be uploaded to the chain in the maintained second transaction pool and the first transaction digests of each of the multiple transactions, and returns the target transaction digest to the first blockchain node; based on the target transaction digest received from the second blockchain node, the target transaction whose first transaction digest matches the target transaction digest is extracted from the target transaction group, and the transaction data of the target transaction is broadcast to the second blockchain node.

[0303] Please refer to Figure 19 In one embodiment, the specific process by which the second blockchain node determines the target transaction digest includes, but is not limited to, the following steps 1910-1920:

[0304] Step 1910: For multiple transactions to be added to the chain in the maintained second transaction pool, perform a digest operation on the transaction data of each of the multiple transactions to be added to the chain to obtain the second transaction digest of each of the multiple transactions to be added to the chain.

[0305] Step 1920: Determine the first transaction digest, which is different from the second transaction digest, as the target transaction digest.

[0306] Steps 1910-1920 are described in detail below.

[0307] In step 1910, for multiple transactions to be added to the chain in the maintained second transaction pool, a preset digest algorithm is used to perform digest operation on the transaction data of each transaction to be added to the chain, converting the transaction data of each transaction to be added to the chain into a fixed-length string, and converting the transaction data from plaintext to ciphertext, so as to obtain the second transaction digest of each transaction to be added to the chain, so that the data size of the second transaction digest of each transaction to be added to the chain is the same, even if the data size of the transaction data is different.

[0308] In step 1920, firstly, for each first transaction digest in the target transaction group, the first transaction digest is compared with the second transaction digests of each transaction to be uploaded to the blockchain in the second transaction pool. If the second transaction digest of the transaction to be uploaded to the blockchain is the same as the first transaction digest, it indicates that the transaction to be uploaded to the blockchain exists in both the first and second transaction pools, and the first blockchain node does not need to broadcast the transaction to be uploaded to the blockchain to the second blockchain node. If the second transaction digest of the transaction to be uploaded to the blockchain is the same as both the first and second transaction digests, it indicates that the transaction to be uploaded to the blockchain corresponding to the first transaction digest exists only in the first transaction pool, and the second transaction pool does not have the transaction to be uploaded to the blockchain corresponding to the first transaction digest. Therefore, the first transaction digest that is different from the second transaction digest is determined as the target transaction digest.

[0309] The advantage of this embodiment is that after receiving multiple first transaction digests broadcast by the first blockchain node, the second blockchain node first uses the same digest algorithm as the first blockchain node to perform digest calculations on each transaction to be added to the chain in its own second transaction pool, obtaining the second transaction digests for each transaction to be added to the chain. Furthermore, by traversing the second transaction pool and using transaction digest comparison, it can quickly and accurately identify the first transaction digests that exist only in the first transaction pool but not in the second transaction pool within the target transaction group range as the target transaction digests, and return the target transaction digests to the first blockchain node to obtain the corresponding transactions to be added to the chain. This method improves the efficiency of transaction comparison between the first and second transaction pools, and since the first and second blockchain nodes broadcast transaction digests of the transactions to be added to the chain, rather than the transaction data itself, it can effectively reduce data transmission overhead.

[0310] Since there are often multiple first transaction summaries or target transaction summaries of transactions to be broadcast on the blockchain, broadcasting each first transaction summary or target transaction summary separately would often result in multiple broadcasts, leading to a large load on transaction broadcasting and low utilization of blockchain resources. Therefore, this disclosure provides a scheme for batch broadcasting transaction summaries or transaction data within the same broadcast cycle, which can effectively reduce the number of broadcasts.

[0311] In one embodiment, there are multiple target transaction summaries and multiple target transactions.

[0312] In this embodiment, step 330 includes:

[0313] Multiple target transaction digests are combined into a digest array, and the digest array is returned to the first blockchain node.

[0314] Here, the summary array refers to a collection of summaries of multiple target transactions.

[0315] Specifically, multiple target transaction summaries can be directly integrated into a set to form an array, resulting in a summary array, which is then broadcast to the first blockchain node as the basic unit.

[0316] The digest array formed by multiple target transaction digests can be represented as follows:

[0317] LackHashes={LackHash i};

[0318] Here, LackHashes refers to the digest array, LackHash. i This refers to the i-th target transaction summary in the summary array. Here, i is an integer greater than 0.

[0319] It should be noted that in the second transaction pool, the query result for finding the transaction to be added to the chain corresponding to the target transaction summary using the code field is empty. For example, the query can be represented as follows:

[0320] POOL_GETTX(LackHash i )==NULL;

[0321] Among them, POOL_GETTX is a transaction pool traversal function that targets the second transaction pool.

[0322] Step 340 includes:

[0323] The transaction data of the target transaction is integrated into a transaction data array, and the transaction data array is broadcast to the second blockchain node.

[0324] Transaction data is used to represent the specific content of the target transaction, associated transaction objects, etc., in plaintext. A transaction data array refers to a collection of transaction data from multiple target transactions.

[0325] Specifically, firstly, for each target transaction digest in the digest array, candidate transactions whose first transaction digest matches the target transaction digest are identified in the target transaction group and selected as target transactions, and their transaction data is extracted. Next, the extracted transaction data is integrated into a set to form an array, resulting in a transaction data array. This transaction data array is then broadcast to the second blockchain node as the basic unit, enabling the second blockchain node to store the transaction data of each target transaction in the transaction data array into the second transaction pool. This allows the target transactions to exist simultaneously in both the first and second transaction pools.

[0326] The advantage of this embodiment is that it enables batch broadcasting of transaction summaries or transaction data within the same broadcast cycle. The first blockchain node integrates multiple first transaction summaries into a single digest array for broadcast, and the second blockchain node also integrates multiple target transaction summaries into a single digest array for broadcast. Ultimately, the first blockchain node also integrates the transaction data of the target transactions into a single transaction data array for unified transmission. This approach effectively reduces the number of broadcasts and lowers the resource consumption for transmitting transaction summaries or transaction data between various blockchain nodes in the blockchain network.

[0327] The following describes the implementation details of a blockchain transaction processing method according to an embodiment of this disclosure.

[0328] The following reference Figures 20A-20B This document details a specific implementation process of the blockchain transaction processing method according to embodiments of the present disclosure.

[0329] like Figure 20AAs shown, a blockchain network includes blockchain nodes A, B, and C. First, a preset threshold is set in the node configuration for blockchain node A. This preset threshold includes the minimum on-chain resource cost (MinFee) for transactions to be uploaded to the blockchain, which blockchain node A will broadcast, and the maximum number of transactions (MaxBatch) within each candidate transaction group to be divided by blockchain node A. The maximum number of transactions within each candidate transaction group to be divided by different blockchain nodes can be different. Further, for the M transactions to be uploaded to the blockchain in the first transaction pool of blockchain node A, blockchain node A will select N transactions as candidate transactions from the M transactions and use a node gain sorter to sort the N candidate transactions, obtaining a candidate transaction queue. The selection of N transactions as candidate transactions from the M transactions can be represented as TXs = POOL_GET(MinFee), where POOL_GET is a function that extracts transactions to be uploaded from the first transaction pool based on the set minimum on-chain resource cost threshold, and TXs refers to the extracted candidate transactions. Furthermore, the first blockchain node will sequentially group the N candidate transactions according to the candidate transaction queue, resulting in K candidate transaction groups. The candidate transactions can be represented in group form as TXs = [SP1, SP2, ..., SP...]. K For example, within the current broadcast cycle, four candidate transaction groups are obtained: Group 1, Group 2, Group 3, and Group 4, in that order. Further, the first blockchain node selects one of the candidate transaction groups as the target transaction group, and compiles the transaction summaries of each transaction in the selected target transaction group into a summary array. This summary array is then broadcast throughout the blockchain network, and the corresponding transactions to be uploaded to the blockchain are verified in a round-robin fashion.

[0330] like Figure 20BAs shown, in a blockchain network, blockchain node A maintains a local transaction pool A and a ledger program A, blockchain node B maintains a local transaction pool B and a ledger program B, and blockchain node C maintains a local transaction pool C and a ledger program C. First, in the broadcast protocol of each blockchain node in the blockchain network, the broadcast period is set to T seconds. At the beginning of the current broadcast period, each blockchain node divides its locally maintained transaction pools, forming multiple candidate transaction groups. Next, taking blockchain node A as an example, it selects a sub-transaction pool from the first transaction pool, that is, it selects one from the multiple candidate transaction groups divided based on the first transaction pool as the target transaction group. Further, the digests of each transaction in the selected sub-transaction pool are integrated into a digest array, and the digest array is broadcast. Based on this, blockchain node B and blockchain node C will query in their respective local transaction pools whether the digest is the same as the digest array. The transaction digest in the digest array that is different from the transaction digest in the local transaction pools maintained by blockchain node B and blockchain node C will be taken as the target transaction digest. The transaction to be put on the chain corresponding to the target transaction digest will be taken as the missing transaction. The digest array formed by the digest of the missing transaction will be sent to blockchain node A to obtain the original text of the transaction from blockchain node A.

[0331] The following reference Figure 21 This document details a specific implementation process of the blockchain transaction processing method according to embodiments of the present disclosure.

[0332] Step 2101: The first blockchain node extracts multiple transactions to be uploaded to the chain as candidate transactions from the first transaction pool it maintains;

[0333] Step 2102: The first blockchain node sorts the candidate transactions according to the resource gains that each candidate transaction brings to the first blockchain node;

[0334] Step 2103: The first blockchain node determines the number of candidate transaction groups to which multiple candidate transactions should be assigned, based on the set maximum number of transactions within a group.

[0335] Step 2104: The first blockchain node assigns each candidate transaction to a candidate transaction group based on the number of groups and the transaction order;

[0336] Step 2105: The first blockchain node performs a modulo operation based on the number of groups and the total number of transaction broadcasts of the first blockchain node to obtain the remainder, and selects the target transaction group corresponding to the current broadcast period from multiple candidate transaction groups based on the remainder;

[0337] Step 2106: The first blockchain node integrates the transaction summaries of each transaction in the target transaction group into a summary array;

[0338] Step 2107: The first blockchain node broadcasts the digest array corresponding to the target transaction group to the second blockchain node;

[0339] Step 2108: The second blockchain node compares the transaction digests of each transaction to be uploaded to the chain in the second transaction pool with the digest array, and determines the transaction digests of each transaction to be uploaded to the chain that are different from those in the second transaction pool as the target transaction digests.

[0340] Step 2109: The second blockchain node returns an array of digests consisting of multiple target transaction digests to the first blockchain node;

[0341] Step 2110: The first blockchain node queries the transaction data of the transaction corresponding to each transaction digest in the target transaction group, and integrates multiple transaction data into a transaction original array;

[0342] Step 2111: The first blockchain node broadcasts the transaction original array to the second blockchain node.

[0343] The specific implementation process of step 2101 is similar to that of step 410. The specific implementation process of step 2102 is similar to that of steps 1210-1220. The specific implementation processes of steps 2103-2104 are similar to those of steps 910-920. The specific implementation process of step 2105 is similar to those of steps 1710-1730. The specific implementation processes of steps 2106-2107 are similar to those of step 330. The specific implementation processes of steps 2108-2109 are similar to those of steps 1910-1920. The specific implementation processes of steps 2110-2111 are similar to those of step 340. To save space, these will not be elaborated further.

[0344] The apparatus and device according to embodiments of this disclosure will now be described.

[0345] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0346] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0347] Figure 22 This is a schematic diagram of the structure of a blockchain transaction processing device 2200 provided in an embodiment of the present disclosure. The blockchain transaction processing device 2200 is executed by a first blockchain node in a blockchain network, and includes:

[0348] The first determining unit 2210 is used to determine multiple candidate transaction groups based on multiple transactions to be put on the chain in the maintained first transaction pool during the current broadcast period.

[0349] The second determining unit 2220 is used to determine the target transaction group from multiple candidate transaction groups based on the total number of transaction broadcasts by the first blockchain node.

[0350] The sending unit 2230 is used to send the first transaction digests of each of the multiple transactions in the target transaction group to the second blockchain node in the blockchain network, so that the second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be put on the chain in the maintained second transaction pool and the first transaction digests of each of the multiple transactions, and returns the target transaction digest to the first blockchain node;

[0351] Broadcast unit 2240 is used to extract the target transaction whose first transaction digest matches the target transaction digest from the target transaction group based on the target transaction digest received from the second blockchain node, and broadcast the transaction data of the target transaction to the second blockchain node.

[0352] Optionally, the first determining unit 2210 includes:

[0353] An extraction module (not shown) is used to extract a first number of transactions to be uploaded to the chain as candidate transactions from the first transaction pool, wherein the first number is less than the total number of transactions to be uploaded to the chain in the first transaction pool.

[0354] A grouping module (not shown) is used to group candidate transactions based on a first number and the maximum number of transactions within a group, resulting in multiple candidate transaction groups, such that the total number of candidate transactions in each candidate transaction group is not greater than the maximum number of transactions within the group.

[0355] Optionally, the extraction module (not shown) is used for:

[0356] In the first transaction pool, determine the on-chain resource overhead for each of the multiple transactions to be added to the blockchain;

[0357] The first number of transactions to be added to the blockchain with resource overhead greater than or equal to the first threshold are selected as candidate transactions.

[0358] Optionally, the extraction module (not shown) is used for:

[0359] In the first transaction pool, determine the time difference between the transaction timestamp and the current time for each of the multiple transactions to be added to the blockchain;

[0360] The first number of transactions to be added to the chain with a time difference greater than or equal to the second threshold are selected as candidate transactions.

[0361] Optionally, the extraction module (not shown) is used for:

[0362] In the first transaction pool, determine the on-chain resource overhead of each of the multiple transactions to be on-chain, and the time difference between the transaction timestamp of each of the multiple transactions to be on-chain and the current time.

[0363] For each transaction to be uploaded to the blockchain, the transaction score is determined based on the resource overhead and time difference for uploading to the blockchain.

[0364] The first number of transactions to be added to the chain with a transaction score greater than or equal to the third threshold are selected as candidate transactions.

[0365] Optionally, the grouping module (not shown) includes:

[0366] A determination submodule (not shown) is used to determine the number of groups for multiple candidate transaction groups based on the quotient of a first number and the maximum number of transactions within the group;

[0367] The allocation submodule (not shown) is used to allocate candidate transactions to candidate transaction groups based on the number of groups, so that each candidate transaction is assigned to a candidate transaction group.

[0368] Optionally, the allocation submodule (not shown) is used for:

[0369] Sort the candidate transactions to obtain the transaction order;

[0370] Initialize the anchor transaction group as the first candidate transaction group among multiple candidate transaction groups;

[0371] Based on transaction order, unassigned candidate transactions are sequentially filled into the anchor transaction group until the total number of candidate transactions in the anchor transaction group equals the maximum number of transactions in the group. The anchor transaction group is then updated with the next candidate transaction group and the process returns to the step of sequentially filling the anchor transaction group with unassigned candidate transactions based on transaction order until all candidate transactions are assigned.

[0372] Optionally, the candidate transactions are sorted to obtain the transaction order, including:

[0373] For each candidate transaction, determine the resource gain that the first blockchain node can obtain on the candidate transaction;

[0374] Based on resource gain, the candidate transactions are sorted to obtain the transaction order.

[0375] Optionally, the second determining unit 2220 is used for:

[0376] Determine the number of candidate transaction groups and the group index of each candidate transaction group;

[0377] The target remainder is obtained by performing a modulo operation based on the number of groups and the total number of transaction broadcasts.

[0378] The target transaction group is determined from multiple candidate transaction groups based on the target remainder and the grouping index.

[0379] Optionally, the transmitting unit 2230 is used for:

[0380] For multiple transactions to be uploaded to the blockchain in the second transaction pool, a digest operation is performed on the transaction data of each transaction to be uploaded to the blockchain to obtain the second transaction digest of each transaction to be uploaded to the blockchain.

[0381] The first transaction digest, which is different from the second transaction digest, is determined as the target transaction digest.

[0382] Optionally, there may be multiple target transaction summaries, and there may be multiple target transactions;

[0383] The transmitting unit 2230 is used for:

[0384] Multiple target transaction digests are integrated into a digest array, and the digest array is returned to the first blockchain node;

[0385] Broadcast unit 2240 is used for:

[0386] The transaction data of the target transaction is integrated into a transaction data array, and the transaction data array is broadcast to the second blockchain node.

[0387] Optionally, the maximum number of transactions within a candidate transaction group is determined in the following way:

[0388] The third determining unit (not shown) is used to determine the operating status parameters and load status parameters of the first blockchain node in the previous broadcast cycle of the current broadcast cycle;

[0389] The fourth determining unit (not shown) is used to determine the node performance score of the first blockchain node based on the operating status parameters and load status parameters.

[0390] The fifth determining unit (not shown) is used to determine the maximum number of transactions within a group based on the node performance score.

[0391] Optionally, the running status parameters include the data transmission rate and packet loss rate of the first blockchain node in the previous broadcast cycle, and the load status parameters include the CPU utilization, memory utilization and bandwidth utilization of the first blockchain node in the previous broadcast cycle.

[0392] The fourth determining unit (not shown) is used for:

[0393] The first score is determined based on the data transmission rate and packet loss rate.

[0394] The second score is determined based on CPU utilization, memory utilization, and bandwidth utilization.

[0395] The node performance score is determined based on the first score and the second score.

[0396] Optionally, the duration of the current broadcast cycle is determined in the following way:

[0397] Determine the network bandwidth and network structure of the blockchain network;

[0398] The network score of a blockchain network is determined based on network bandwidth and network structure.

[0399] The duration of the cycle is determined based on the network score.

[0400] Reference Figure 23 , Figure 23 To implement the structural block diagram of the terminal portion of the blockchain transaction processing method according to embodiments of this disclosure, the terminal includes: a radio frequency (RF) circuit 2310, a memory 2315, an input unit 2330, a display unit 2340, a sensor 2350, an audio circuit 2360, a wireless fidelity (WiFi) module 2370, a processor 2380, and a power supply 2390, etc. Those skilled in the art will understand that... Figure 23 The terminal structure shown does not constitute a limitation on mobile phones or computers and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0401] The RF circuit 2310 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 2380; in addition, it transmits uplink data to the base station.

[0402] The memory 2315 can be used to store software programs and modules. The processor 2380 executes various functional applications and data processing of the target terminal by running the software programs and modules stored in the memory 2315.

[0403] The input unit 2330 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the target terminal. Specifically, the input unit 2330 may include a touch panel 2331 and other input devices 2332.

[0404] Display unit 2340 can be used to display input or provided information, as well as various menus of the target terminal. Display unit 2340 may include display panel 2341.

[0405] Audio circuitry 2360, speaker 2361, and microphone 2362 provide an audio interface.

[0406] In this embodiment, the processor 2380 included in the terminal can execute the blockchain transaction processing method of the previous embodiment.

[0407] The terminals disclosed in this embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to data security, blockchain, data storage, and information technology.

[0408] Figure 24 This is a partial structural block diagram of a server for implementing the blockchain transaction processing method of this disclosure. The server can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 2422 (e.g., one or more processors) and memory 2432, and one or more storage media 2430 (e.g., one or more mass storage devices) for storing application programs 2442 or data 2444. The memory 2432 and storage media 2430 can be temporary or persistent storage. The program stored in the storage media 2430 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 2422 may be configured to communicate with the storage media 2430 and execute the series of instruction operations in the storage media 2430 on the server.

[0409] The server may also include one or more power supplies 2423, one or more wired or wireless network interfaces 2450, one or more input / output interfaces 2458, and / or one or more operating systems 2441, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0410] The central processing unit 2422 in the server can be used to execute the blockchain transaction processing method of the present disclosure embodiments.

[0411] This disclosure also provides a computer-readable storage medium for storing program code for executing the blockchain transaction processing methods of the foregoing embodiments.

[0412] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the blockchain transaction processing method described above.

[0413] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0414] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0415] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0416] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0417] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0418] The units described as separate components may or may not be physically separate. The 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0419] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0420] If the integrated unit is implemented as 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 this disclosure, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0421] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0422] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A blockchain transaction processing method, characterized in that, The method, executed by the first blockchain node in the blockchain network, includes: Within the current broadcast cycle, multiple candidate transaction groups are determined based on the multiple transactions to be uploaded to the chain in the first transaction pool that are maintained; Based on the total number of transaction broadcasts by the first blockchain node, the target transaction group is determined from the plurality of candidate transaction groups; The first transaction digests of each of the multiple transactions in the target transaction group are sent to the second blockchain node in the blockchain network, so that the second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be put on the chain in the maintained second transaction pool and the first transaction digests of each of the multiple transactions, and returns the target transaction digest to the first blockchain node; Based on the target transaction digest received from the second blockchain node, target transactions whose first transaction digest matches the target transaction digest are extracted from the target transaction group, and the transaction data of the target transaction is broadcast to the second blockchain node.

2. The method according to claim 1, characterized in that, The multiple transactions awaiting on-chain processing in the first transaction pool under maintenance are grouped into multiple candidate transaction groups, including: In the first transaction pool, a first number of transactions to be uploaded to the chain are extracted as candidate transactions, wherein the first number is less than the total number of transactions to be uploaded to the chain in the first transaction pool. Based on the first number and the maximum number of transactions within the candidate transaction group, the candidate transactions are grouped to obtain the plurality of candidate transaction groups, such that the total number of candidate transactions in each candidate transaction group is not greater than the maximum number of transactions within the group.

3. The method according to claim 2, characterized in that, The step of extracting a first number of transactions to be uploaded to the blockchain as candidate transactions from the first transaction pool includes: In the first transaction pool, the on-chain resource overhead of each of the plurality of transactions to be on-chain is determined; The first number of transactions to be added to the chain with the resource overhead being greater than or equal to the first threshold are selected as candidate transactions.

4. The method according to claim 2, characterized in that, The step of extracting a first number of transactions to be uploaded to the blockchain as candidate transactions from the first transaction pool includes: In the first transaction pool, the time difference between the transaction timestamp and the current time is determined for each of the multiple transactions to be uploaded to the blockchain; The first number of transactions to be added to the chain with a time difference greater than or equal to the second threshold are selected as candidate transactions.

5. The method according to claim 2, characterized in that, The step of extracting a first number of transactions to be uploaded to the blockchain as candidate transactions from the first transaction pool includes: In the first transaction pool, the on-chain resource cost of each of the multiple transactions to be on-chain, and the time difference between the transaction timestamp of each of the multiple transactions to be on-chain and the current time are determined. For each transaction to be uploaded to the blockchain, the transaction score of the transaction to be uploaded to the blockchain is determined based on the blockchain resource overhead and the time difference; The first number of transactions to be added to the chain whose transaction scores are greater than or equal to the third threshold are selected as candidate transactions.

6. The method according to claim 2, characterized in that, The process of grouping the candidate transactions based on the first number and the maximum number of transactions within each candidate transaction group to obtain the plurality of candidate transaction groups includes: The number of candidate transaction groups is determined based on the quotient of the first number and the maximum number of transactions within the group; Based on the number of groups, the candidate transactions are assigned to the candidate transaction groups, such that each candidate transaction is assigned to one candidate transaction group.

7. The method according to claim 6, characterized in that, The step of assigning the candidate transactions to the candidate transaction groups based on the number of groups includes: The candidate transactions are sorted to obtain the transaction order; The anchor transaction group is initialized as the first candidate transaction group among the plurality of candidate transaction groups; Based on the transaction order, the unallocated candidate transactions are sequentially filled into the anchor transaction group until the total number of candidate transactions in the anchor transaction group equals the maximum number of transactions in the group. The anchor transaction group is then updated with the next candidate transaction group, and the process returns to the step of sequentially filling the unallocated candidate transactions into the anchor transaction group based on the transaction order until all candidate transactions are allocated.

8. The method according to claim 7, characterized in that, The step of sorting the candidate transactions to obtain the transaction order includes: For each of the candidate transactions, determine the resource gain that the first blockchain node can obtain on the candidate transaction; Based on the resource gain, the candidate transactions are sorted to obtain the transaction order.

9. The method according to claim 1, characterized in that, The determination of the target transaction group from the plurality of candidate transaction groups based on the total number of transaction broadcasts of the first blockchain node includes: Determine the number of candidate transaction groups and the group index of each candidate transaction group; The target remainder is obtained by performing a modulo operation based on the number of groups and the total number of transaction broadcasts. The target transaction group is determined from the plurality of candidate transaction groups based on the target remainder and the grouping index.

10. The method according to claim 1, characterized in that, The second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be uploaded to the chain in the maintained second transaction pool, and the first transaction digests of each of the multiple transactions, including: For multiple transactions to be uploaded to the blockchain in the maintained second transaction pool, a digest operation is performed on the transaction data of each of the multiple transactions to be uploaded to the blockchain to obtain the second transaction digest of each of the multiple transactions to be uploaded to the blockchain. The first transaction digest that is different from the second transaction digest is determined as the target transaction digest.

11. The method according to claim 1, characterized in that, There are multiple target transaction digests, and there are multiple target transactions; Returning the target transaction digest to the first blockchain node includes: integrating multiple target transaction digests into a digest array, and returning the digest array to the first blockchain node; The step of broadcasting the transaction data of the target transaction to the second blockchain node includes: integrating the transaction data of the target transaction into a transaction data array, and broadcasting the transaction data array to the second blockchain node.

12. The method according to claim 1, characterized in that, The maximum number of transactions within a candidate transaction group is determined in the following way: Determine the operating status parameters and load status parameters of the first blockchain node in the previous broadcast cycle of the current broadcast cycle; Based on the operating status parameters and the load status parameters, the node performance score of the first blockchain node is determined; Based on the node performance score, the maximum number of transactions within the group is determined.

13. The method according to claim 12, characterized in that, The operating status parameters include the data transmission rate and packet loss rate of the first blockchain node in the previous broadcast cycle, and the load status parameters include the CPU utilization, memory utilization, and bandwidth utilization of the first blockchain node in the previous broadcast cycle. The process of determining the node performance score of the first blockchain node based on the operating status parameters and the load status parameters includes: A first score is determined based on the data transmission rate and the packet loss rate; The second score is determined based on the CPU utilization, memory utilization, and bandwidth utilization. The node performance score is determined based on the first score and the second score.

14. The method according to claim 1, characterized in that, The duration of the current broadcast cycle is determined in the following way: Determine the network bandwidth and network structure of the blockchain network; The network score of the blockchain network is determined based on the network bandwidth and the network structure. The period duration is determined based on the network score.

15. A blockchain transaction processing device, characterized in that, Executed by the first blockchain node in the blockchain network, the device includes: The first determining unit is used to determine multiple candidate transaction groups based on multiple transactions to be uploaded to the chain in the maintained first transaction pool during the current broadcast period. The second determining unit is used to determine the target transaction group from the plurality of candidate transaction groups based on the total number of transaction broadcasts by the first blockchain node. The sending unit is configured to send the first transaction digests of each of the multiple transactions in the target transaction group to a second blockchain node in the blockchain network, so that the second blockchain node determines the target transaction digest based on the second transaction digests of each of the multiple transactions to be uploaded to the chain in the maintained second transaction pool and the first transaction digests of each of the multiple transactions, and returns the target transaction digest to the first blockchain node; The broadcasting unit is configured to extract the target transaction whose first transaction digest matches the target transaction digest from the target transaction group based on the target transaction digest received from the second blockchain node, and broadcast the transaction data of the target transaction to the second blockchain node.

16. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the blockchain transaction processing method according to any one of claims 1 to 14.

17. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the blockchain transaction processing method according to any one of claims 1 to 14.

18. A computer program product comprising a computer program that is read and executed by a processor of an electronic device, causing the electronic device to perform the blockchain transaction processing method according to any one of claims 1 to 14.

Images