Block chain processing method, related device and medium

Abstract

The invention provides a block chain processing method, a related device and a medium. The method is applied to a target consensus node in a plurality of consensus nodes in a block chain network, and comprises the following steps: obtaining a plurality of to-be-linked transaction queues maintained by the target consensus node, each to-be-linked transaction queue storing a to-be-linked transaction of one consensus node in the plurality of consensus nodes; preferentially taking out the to-be-linked transaction from a target transaction queue corresponding to a target consensus node in the plurality of to-be-linked transaction queues, and packaging the to-be-linked transaction to a first target block; if the target transaction queue is empty and the size of the first target block is still smaller than a first threshold value, screening out a screened transaction queue of which the queue length exceeds a second threshold value from to-be-linked transaction queues corresponding to other consensus nodes in the plurality of consensus nodes; and taking out the to-be-chained transaction from the screened transaction queue, and supplementing the to-be-chained transaction to the first target block. According to the invention, the block output delay can be reduced and the block output efficiency is improved. The method can be applied to various scenes such as block chains and artificial intelligence.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain technology, and in particular to a blockchain processing method, related devices and media. Background Art

[0002] At present, in the blockchain system, when each consensus node packages transactions into blocks and records them on the blockchain according to the predetermined block rules, it is often limited by factors such as node load and node processing capacity, resulting in problems such as block delays and low block efficiency. Summary of the invention

[0003] The embodiments of the present disclosure provide a blockchain processing method, related devices and media, which can reduce block generation delay and improve block generation efficiency.

[0004] According to one aspect of the present disclosure, a blockchain processing method is provided, which is applied to a target consensus node among multiple consensus nodes in a blockchain network, and the method includes:

[0005] Acquire multiple transaction queues to be uploaded to the chain maintained by the target consensus node, each of the transaction queues to be uploaded to the chain stores the transaction to be uploaded to the chain of one of the consensus nodes among the consensus nodes;

[0006] From the target transaction queue corresponding to the target consensus node in the plurality of transaction queues to be on-chain, the transaction to be on-chain is preferentially taken out, and packaged into the first target block;

[0007] If the size of the first target block is still smaller than the first threshold after the target transaction queue is empty, a filtered transaction queue whose queue length exceeds the second threshold is filtered out from the to-be-uploaded transaction queues corresponding to other consensus nodes among the plurality of consensus nodes;

[0008] The transaction to be put on the chain is taken out from the filtered transaction queue and added to the first target block to put the first target block on the chain.

[0009] According to one aspect of the present disclosure, a blockchain processing device is provided, which is applied to a target consensus node among multiple consensus nodes in a blockchain network, and the device includes:

[0010] A queue acquisition unit, used to acquire a plurality of to-be-online transaction queues maintained by the target consensus node, each of the to-be-online transaction queues storing the to-be-online transaction of one of the consensus nodes among the plurality of the consensus nodes;

[0011] A packaging unit, used to preferentially take out the to-be-chained transaction from the target transaction queue corresponding to the target consensus node in the plurality of to-be-chained transaction queues, and package them into a first target block;

[0012] A screening unit, configured to screen out a screened transaction queue whose queue length exceeds a second threshold from the to-be-uploaded transaction queues corresponding to other consensus nodes among the plurality of consensus nodes if the size of the first target block is still smaller than the first threshold after the target transaction queue is emptied;

[0013] A supplement unit is used to take out the transaction to be put on the chain from the filtered transaction queue and supplement it to the first target block to put the first target block on the chain.

[0014] Optionally, the supplementing unit is specifically used to:

[0015] For each of the filtered transaction queues, determine a first difference between the queue length and the second threshold, and filter out the first difference filtered transactions to be uploaded to the chain with the earliest timestamp in the filtered transaction queue;

[0016] The plurality of filtered transaction queues are first sorted in descending order of the queue lengths, and the filtered transactions to be on-chain are taken out from the filtered transaction queues according to the first sort to fill the first target block until the size of the first target block reaches the first threshold.

[0017] Optionally, the supplementing unit is specifically used to:

[0018] For each of the filtered transaction queues, determine the transactions marked to be uploaded to the chain in the filtered transaction queue;

[0019] The plurality of filtered transaction queues are subjected to a second sorting in descending order of the number of the marked transactions to be chained, and the marked transactions to be chained are taken out from the filtered transaction queues according to the second sorting to fill the first target block until the size of the first target block reaches the first threshold.

[0020] Optionally, the transaction marked to be on-chain is marked by a marking consensus node among the plurality of consensus nodes in the following manner:

[0021] Obtaining a second difference between the number of transactions to be on-chain of the marked consensus node and the first threshold;

[0022] The second difference of the transactions to be put on the chain with the earliest timestamp among the transactions to be put on the chain of the marked consensus node are evenly distributed to other consensus nodes, and the distributed transactions to be put on the chain are marked.

[0023] Optionally, the transaction marked to be on-chain is marked by a marking consensus node among the plurality of consensus nodes in the following manner:

[0024] Obtaining a second difference between the number of transactions to be on-chain of the marked consensus node and the first threshold;

[0025] Obtaining the node processing capacity and credit of each other consensus node;

[0026] Determining the allocation tendency of each other consensus node based on the node processing capacity and the credit;

[0027] The second difference transaction to be on-chain with the earliest timestamp among the transactions to be on-chain of the marked consensus node is allocated to other consensus nodes according to the allocation tendency of each other consensus node, and the allocated transaction to be on-chain is marked.

[0028] Optionally, the plurality of transaction queues to be uploaded are generated in the following manner:

[0029] In response to receiving the transaction to be on-chain from the client, the transaction to be on-chain received from the client is saved in the target transaction queue corresponding to the target consensus node, and the transaction to be on-chain is forwarded to other consensus nodes;

[0030] In response to receiving the transaction to be on-chain from the other consensus nodes, the transaction to be on-chain received from the other consensus nodes is saved in the transaction queue to be on-chain corresponding to the other consensus nodes, without forwarding the transaction to be on-chain.

[0031] Optionally, the method is performed according to a block generation cycle; and the supplementing unit is used to:

[0032] Taking out the transaction to be put on the chain from the filtered transaction queue of the current cycle, and adding it to the first target block, so as to put the first target block on the chain;

[0033] The blockchain processing device further includes a transaction fetching unit, which is specifically used to:

[0034] In response to not receiving the consensus block to be negotiated of the previous consensus node of the target consensus node in the previous block generation cycle, taking out the transaction to be negotiated from the transaction to be negotiated corresponding to the previous consensus node in the plurality of transaction queues to be negotiated, and packaging it into a second target block, so as to link the second target block to the chain.

[0035] Optionally, the method is performed according to a block generation cycle; and the supplementing unit is used to:

[0036] In response to not receiving a consensus block of a previous consensus node of the target consensus node in a previous block generation cycle, taking out the transaction to be uploaded from the transaction queue to be uploaded corresponding to the previous consensus node in the plurality of transaction queues to be uploaded, and adding it to the first target block;

[0037] If the size of the first target block is still smaller than the first threshold, in the current block generation cycle, the to-be-chained transaction is taken out from the filtered transaction queue and added to the first target block to chain the first target block.

[0038] Optionally, the previous consensus node of the target consensus node is determined based on a block generation order, and the block generation order is determined in the following manner:

[0039] A status collection unit, used to collect the block status of multiple consensus nodes;

[0040] A state determination unit, configured to determine the overall block production state of the blockchain network according to the block production states of the plurality of consensus nodes;

[0041] A first sequence determining unit, configured to determine that the block generation sequence is a predetermined sequence if it is determined that the overall block generation state satisfies a predetermined condition;

[0042] The second order determination unit is used to determine the block generation order based on the block generation status and credit of each of the consensus nodes if it is determined that the overall block generation status does not meet the predetermined condition.

[0043] Optionally, the predetermined order is determined by:

[0044] Obtain the time when each of the consensus nodes joins the blockchain network, and obtain the network access time of each of the consensus nodes;

[0045] The predetermined order is determined based on the network access time.

[0046] Optionally, the second sequence determining unit includes:

[0047] A first score determining unit, configured to determine a first score for each of the consensus nodes based on the block generation status;

[0048] A second score determination unit, configured to determine a second score for each of the consensus nodes based on the credit level;

[0049] a total score determining unit, configured to determine a total score of each of the consensus nodes based on a weighted sum of the first score and the second score;

[0050] A block generation order determination unit is used to determine the block generation order based on the total score.

[0051] Optionally, the block generation status includes node processing capability and block generation delay; and the first score determination unit is specifically configured to:

[0052] Determining a first sub-score based on the node processing capability;

[0053] Determining a second sub-score based on the block delay;

[0054] The first score is determined based on the first sub-score and the second sub-score.

[0055] Optionally, the credit includes transaction confirmation credit and block generation credit; the second score determination unit is specifically used to:

[0056] Determining a third sub-score based on the transaction confirmation creditworthiness;

[0057] Determining a fourth sub-score based on the block credit;

[0058] The second score is determined based on the third sub-score and the fourth sub-score.

[0059] Optionally, the block generation period is determined by:

[0060] A speed unit, used to obtain the real-time network loading speed of the blockchain network;

[0061] A transaction total number determination unit, configured to determine the total number of transactions to be uploaded in the blockchain network based on the transactions to be uploaded in the plurality of consensus nodes;

[0062] The cycle determination unit is used to determine the block generation cycle based on the real-time loading speed of the network and the total number of transactions to be uploaded to the chain.

[0063] Optionally, the period determination unit is specifically configured to:

[0064] Determining a third score based on the real-time network loading speed;

[0065] Determining a fourth score based on the total number of transactions to be uploaded to the chain;

[0066] The block generation period is determined based on the third score and the fourth score.

[0067] Optionally, the previous consensus node of the target consensus node is determined based on a block generation order, and the block generation order is determined in the following manner:

[0068] Obtain the block height of the first target block;

[0069] If the block height meets the predetermined conditions, the block generation order is determined based on the block generation status and credit of each consensus node.

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

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

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

[0073] In the disclosed embodiment, multiple queues of transactions to be uploaded maintained by the target consensus node are obtained, and multiple transactions to be uploaded received by the target consensus node are saved in the form of queues, thereby improving the storage orderliness of transactions to be uploaded. Next, the target transaction queue corresponding to the target consensus node in the multiple queues of transactions to be uploaded is preferentially taken out and packaged into the first target block, so that the transactions to be uploaded in the target transaction queue are preferentially packaged and uploaded. Furthermore, if the size of the first target block is still less than the first threshold after the target transaction queue is emptied, a filtered transaction queue whose queue length exceeds the second threshold is screened out from the to-be-linked transaction queues corresponding to other consensus nodes among the multiple consensus nodes; the to-be-linked transactions are taken out from the filtered transaction queue and added to the first target block. Based on the node processing capacity of the target consensus node, after the to-be-linked transactions in the target transaction queue are preferentially processed, if there is still free space in the first target block, the to-be-linked transactions in the filtered transaction queue with a longer queue length are added to the first target block, so that the to-be-linked transactions in the to-be-linked transaction queues corresponding to other consensus nodes with higher loads can be processed as soon as possible, which is conducive to improving transaction processing efficiency, and can also alleviate the block production pressure of consensus nodes with more to-be-processed transactions, thereby reducing block production delays and improving block production efficiency.

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

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

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

[0077] Figure 2 A schematic diagram showing the application of the blockchain processing method according to an embodiment of the present disclosure in a transaction on-chain scenario;

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

[0079] Figure 4 is a flowchart of obtaining multiple transaction queues to be uploaded according to an embodiment of the present disclosure;

[0080] Figure 5 It is a schematic diagram of an implementation process of generating multiple transaction queues to be uploaded to the chain according to an embodiment of the present disclosure;

[0081] Figure 6 It is a schematic diagram of the implementation process of the target consensus node broadcasting the transaction to be on-chain according to an embodiment of the present disclosure;

[0082] Figure 7A-7B It is a schematic diagram of an implementation process of packaging multiple transactions to be uploaded to a target transaction queue into a first target block according to an embodiment of the present disclosure;

[0083] Figure 8 yes Figure 3 Flowchart of taking out the transactions to be uploaded from the filtered transaction queue and adding them to the first target block in step 340;

[0084] Fig. 9 yes Figure 3 Schematic diagram of the implementation process of taking out the to-be-uploaded transactions from the filtered transaction queue and adding them to the first target block in step 340;

[0085] Fig.10 yes Figure 3 Another flowchart of taking out the to-be-uploaded transactions from the filtered transaction queue and adding them to the first target block in step 340;

[0086] Fig.11 is a flow chart of determining a transaction to be marked on-chain according to an embodiment of the present disclosure;

[0087] Fig.12 is a schematic diagram of an implementation process of determining and marking transactions to be uploaded to the chain according to another embodiment of the present disclosure;

[0088] Fig.13 is a flow chart of determining a transaction to be marked on-chain according to another embodiment of the present disclosure;

[0089] Figure 14A-14B is a schematic diagram of an implementation process of determining and marking transactions to be uploaded to the chain according to another embodiment of the present disclosure;

[0090] Fig.15A It is a schematic diagram of an implementation process of taking out transactions to be uploaded from a target transaction queue and a filtered transaction queue and packaging them into a first target block according to an embodiment of the present disclosure;

[0091] Fig. 15B It is a schematic diagram of an implementation process of packaging the to-be-uploaded transactions of the to-be-consensus block of the previous consensus node into a second target block according to an embodiment of the present disclosure;

[0092] Fig.16 yes Figure 3 Another flowchart of taking out the to-be-uploaded transactions from the filtered transaction queue and adding them to the first target block in step 340;

[0093] Fig.17 is a flowchart for determining a block order according to an embodiment of the present disclosure;

[0094] Fig.18 is a flowchart for determining a predetermined order according to an embodiment of the present disclosure;

[0095] Fig.19 is a schematic diagram of an implementation process of determining a predetermined order according to an embodiment of the present disclosure;

[0096] Fig. 20 yes Fig.17 A flowchart of determining the block generation order based on the block generation status and credit of each consensus node in step 1740;

[0097] Fig.21 is a schematic diagram of an implementation process of determining a block generation order according to an embodiment of the present disclosure;

[0098] Fig. 22 is a flowchart for determining a block order according to another embodiment of the present disclosure;

[0099] Fig.23 is a flowchart of determining a block generation period according to an embodiment of the present disclosure;

[0100] Fig.24 is a module diagram of a blockchain processing device according to an embodiment of the present disclosure;

[0101] Fig.25is a terminal structure diagram of a blockchain processing method according to an embodiment of the present disclosure;

[0102] Fig.26 1 is a server structure diagram of a blockchain processing method according to an embodiment of the present disclosure. DETAILED DESCRIPTION

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

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

[0105] Artificial Intelligence (AI): It is the theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results. In other words, artificial intelligence is a comprehensive technology in computer science. It attempts to understand the essence of intelligence and produce a new intelligent machine that can respond in a similar way to human intelligence. Artificial intelligence is to study the design principles and implementation methods of various intelligent machines so that machines have the functions of perception, reasoning and decision-making. Artificial intelligence technology is a comprehensive discipline that covers a wide range of fields, including both hardware-level technology and software-level technology. The basic technologies of artificial intelligence generally include sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, pre-trained model technology, operation / interaction system, mechatronics, etc. Among them, the pre-trained model is also called the large model or the basic model. After fine-tuning, it can be widely used in downstream tasks in various major directions of artificial intelligence. Artificial intelligence software technology mainly includes computer vision technology, speech processing technology, natural language processing technology, and machine learning / deep learning. With the research and advancement of artificial intelligence technology, artificial intelligence technology has been studied and applied in many fields, such as common smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, unmanned driving, automatic driving, drones, robots, smart medical care, smart customer service, etc. I believe that with the development of technology, artificial intelligence technology will be applied in more fields and play an increasingly important role.

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

[0107] Alliance blockchain: Alliance chain for short, is for a specific group, and only authorized nodes can join a specific blockchain network. Nodes in the alliance chain need to be authenticated and registered, and encryption is usually not involved in the consensus process. Member nodes have a common goal, but do not fully trust each other in terms of maintaining verification data. Compared with the public chain, the nodes of the alliance chain usually have good connections, higher verification and confirmation speeds, faster block times, and lower system maintenance costs. Combined with the latest technological developments in blockchain, the alliance chain can enable internal members to jointly maintain the ledger. At the same time, the registration mechanism can limit the behavior of participating nodes and flexibly handle permissions. To a certain extent, a decentralized and distributed system has been built, which gets rid of the single point of failure and other security risks brought by the only central organization, solves the trust problem, and can be applied to financial, supply chain, public welfare and other application scenarios.

[0108] At present, in the blockchain system, when each consensus node packages transactions into blocks and records them on the blockchain according to the predetermined block rules, it is often limited by factors such as node load and node processing capacity, resulting in problems such as block delays and low block efficiency.

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

[0110] Figure 1 It is a system architecture diagram applied by the blockchain-based data processing method according to an embodiment of the present disclosure. It includes an object terminal 140, the Internet 130, a gateway 120, a blockchain network 110, etc.

[0111] The object terminal 140 includes various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, vehicle-mounted terminals, home theater terminals, and dedicated terminals. In addition, it can be a single device or a collection of multiple devices. The object terminal 140 can communicate with the Internet 130 in a wired or wireless manner to exchange data. Among them, the object terminal 140 includes a transaction processing system, which is used to chain the transaction data input by the object so that the transaction data is stored on the blockchain.

[0112] See also Figure 1The blockchain network 110 shown includes a consensus network. A consensus network refers to a network that reaches consensus on transactions to be uploaded to the blockchain and uploads them to the blockchain. It includes multiple consensus nodes. A consensus node is a blockchain node. A consensus node or a blockchain node can be a server in a blockchain network or an object terminal connected to a blockchain network. The specific form of a consensus node or a blockchain node is not limited here.

[0113] The gateway 120 is also called an internetwork connector or a protocol converter. The gateway realizes network interconnection at the transport layer and is a computer system or device that acts as a converter. The gateway is a translator between two systems that use different communication protocols, data formats or languages, or even completely different architectures. At the same time, the gateway can also provide filtering and security functions. The message sent by the object terminal 140 to the blockchain network 110 must be sent to the corresponding blockchain network 110 through the gateway 120. The message sent by the blockchain network 110 to the object terminal 140 must also be sent to the corresponding object terminal 140 through the gateway 120.

[0114] The embodiments of the present disclosure can be applied in various scenarios, such as Figure 2 The transaction chain scenario shown in the figure.

[0115] like Figure 2As shown, the blockchain network contains 8 consensus nodes, namely consensus node 1, target consensus node, consensus node 2, consensus node 3, consensus node 4, consensus node 5, consensus node 6, and consensus node 7. Among them, each consensus node is numbered according to the preset block order, and the block number of each consensus node is obtained, so that each consensus node can be block-produced in sequence according to the size of the block number. Among them, the block number of consensus node 1 is ①, the block number of the target consensus node is ②, the block number of consensus node 2 is ⑦, the block number of consensus node 3 is ⑧, the block number of consensus node 4 is ③, the block number of consensus node 5 is ④, the block number of consensus node 6 is ⑤, and the block number of consensus node 7 is ⑥. When it is the turn of the target consensus node to produce a block, multiple transactions are taken out from the transaction pool of the target consensus node and packaged into the target block, wherein the target block can accommodate 4 transactions. Specifically, transaction queue 1 is a queue formed by multiple transactions received by the target consensus node from the client. Transaction queue 2 to transaction queue 8 are queues formed by multiple transactions received from other consensus nodes of the blockchain network. Further, first take out transaction 1 and transaction 2 from transaction queue 1 and pack them into the target block. After taking out transaction 1 and transaction 2, transaction queue 1 is empty. At this time, the target block can continue to accommodate two transactions. Based on this, the transaction queue with the largest queue length from transaction queue 2 to transaction queue 8 is screened to obtain transaction queue 3, and transaction 11 and transaction 12 are taken out from transaction queue 3 and packed into the target block, so that the target block reaches the transaction capacity limit. Further, the target consensus node will broadcast the target block to other consensus nodes. After receiving the feedback of consent to chain from other consensus nodes, the target consensus node will chain the target block to the blockchain.

[0116] General description of the disclosed embodiments

[0117] According to one embodiment of the present disclosure, a blockchain processing method is provided.

[0118] This blockchain processing method is generally used in alliance chain platforms or enterprise-level blockchain scenarios, such as Figure 2 The transaction on-chain scenario shown. The disclosed embodiment provides a solution that preferentially packages the transactions to be on-chain received from the client into the target block, and supplements the transactions to be on-chain received from other consensus nodes into the target block, which can reduce the block delay and improve the block efficiency.

[0119] The blockchain processing method of the disclosed embodiment is applied to a target consensus node among multiple consensus nodes in a blockchain network.

[0120] like Figure 3 As shown, a blockchain processing method according to an embodiment of the present disclosure may include:

[0121] Step 310: Obtain multiple transaction queues to be uploaded to the chain maintained by the target consensus node;

[0122] Step 320: Take out the transactions to be uploaded from the target transaction queue corresponding to the target consensus node in the multiple transaction queues to be uploaded, and pack them into the first target block;

[0123] Step 330: If the size of the first target block is still smaller than the first threshold after the target transaction queue is empty, filter out the filtered transaction queues whose queue length exceeds the second threshold from the to-be-uploaded transaction queues corresponding to other consensus nodes among the multiple consensus nodes;

[0124] Step 340: Take out the transactions to be uploaded from the filtered transaction queue and add them to the first target block.

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

[0126] In step 310, multiple transaction queues to be uploaded to the chain maintained by the target consensus node are obtained.

[0127] The transaction queue to be on-chain is a queue formed by arranging multiple transactions to be on-chain in the target consensus node in a certain order. Each transaction queue to be on-chain stores the transactions to be on-chain of one consensus node among multiple consensus nodes. The transaction sources of the transactions to be on-chain in each transaction queue to be on-chain are the same.

[0128] Transactions to be uploaded to the blockchain refer to transactions received by the consensus node that need to be uploaded to the blockchain. Each transaction to be uploaded to the blockchain is used to indicate the detailed information of a resource exchange process.

[0129] It should be noted that each transaction to be put on the chain has a timestamp, which is used to record the time point when the transaction to be put on the chain occurs.

[0130] In some embodiments, the target consensus node maintains multiple queues of transactions to be chained in the transaction pool. The transaction pool is used to store multiple transactions received by the target consensus node from the client or other consensus nodes. Furthermore, when maintaining multiple queues of transactions to be chained, the target consensus node can first classify the transactions to be chained according to the transaction source of each transaction to be chained, and obtain multiple sets of transactions to be chained. Then, for each set of transactions to be chained, sort the transactions to be chained in the set of transactions to be chained according to the timestamp to obtain multiple queues of transactions to be chained. In the queue of transactions to be chained, the transactions to be chained with earlier timestamps are ranked in the front, and the transactions to be chained with later timestamps are ranked in the back.

[0131] In the specific implementation of this embodiment, the transaction pool of the target consensus node is first obtained. Then, multiple transaction queues to be uploaded to the chain maintained in the transaction pool are extracted.

[0132] In step 320, the transactions to be chained are preferentially taken out from the target transaction queue corresponding to the target consensus node in the multiple transaction queues to be chained and packaged into the first target block.

[0133] The target transaction queue refers to the queue consisting of transactions to be uploaded to the chain that the target consensus node receives from the client.

[0134] The first target block refers to the block used to record the transactions to be uploaded to the chain received by the target consensus node from the client.

[0135] In the specific implementation of this embodiment, first determine the target transaction queue of the target consensus node from multiple transaction queues to be on-chain. Then, take out multiple transactions to be on-chain from the target transaction queue in the order in which they are arranged in the queue. Finally, pack the taken out multiple transactions to be on-chain into the first target block.

[0136] In step 330, if the size of the first target block is still smaller than the first threshold after the target transaction queue is emptied, a filtered transaction queue whose queue length exceeds the second threshold is filtered out from the to-be-uploaded transaction queues corresponding to other consensus nodes among the multiple consensus nodes.

[0137] The size of the first target block refers to the total number of transactions to be uploaded to the chain that are packaged into the first target block.

[0138] The first threshold is used to measure whether the total number of transactions to be uploaded to the chain that are packaged into the first target block meets the predetermined requirement.

[0139] The second threshold is used to measure the congestion level of each queue of transactions to be on-chain. The consensus node whose queue length of the queue of transactions to be on-chain exceeds the second threshold is a congested node. The consensus node whose queue length of the queue of transactions to be on-chain does not exceed the second threshold is a non-congested node. The specific value of the second threshold is determined according to actual business needs and is not limited.

[0140] The queue length is determined according to the number of transactions to be uploaded in the transaction queue to be uploaded. When the number of transactions to be uploaded in the transaction queue to be uploaded is 10, the queue length of the transaction queue to be uploaded is 10.

[0141] The filtered transaction queue refers to a transaction queue in which the number of transactions to be uploaded exceeds a second threshold.

[0142] In the specific implementation of this embodiment, according to the size of the first target block, after all the transactions to be chained in the target transaction queue are taken out and packaged into the first target block, the number of transactions to be chained contained in the first target block is checked. If the total number of transactions to be chained in the first target block is still less than the first threshold after the target transaction queue is emptied, it indicates that there is still a certain amount of free space in the first target block, and a part of the transactions to be chained can be filled. Based on this, the number of transactions to be chained in the transaction queue to be chained corresponding to each other consensus node in the multiple consensus nodes is determined. If the number of transactions to be chained exceeds the second threshold, it is considered that the queue length of the transaction queue to be chained of the consensus node is too large, the load of the consensus node is large, and this type of consensus node is more likely to have a block delay. Further, the transaction queue to be chained corresponding to other consensus nodes whose number of transactions to be chained exceeds the second threshold is used as the filtered transaction queue.

[0143] In step 340, the transactions to be uploaded are taken from the filtered transaction queue and added to the first target block.

[0144] When this embodiment is implemented, the transactions to be uploaded are taken from multiple filtered transaction queues and added to the first target block, so that the size of the first target block reaches the first threshold. Specifically, when the transactions to be uploaded are taken from multiple filtered transaction queues, a filtered transaction queue may be randomly selected, and some transactions to be uploaded are randomly taken from the selected filtered transaction queue and added to the first target block; or a filtered transaction queue from which transactions to be uploaded is to be extracted is determined based on certain rules from multiple filtered transaction queues, and the specific transactions to be uploaded are determined based on certain rules, without limitation.

[0145] The specific implementation process of taking out the transactions to be uploaded from the filtered transaction queue and adding them to the first target block will be described in detail below. To save space, it will not be described here.

[0146] It should be noted that after the target consensus node completes the packaging of the first target block, it will broadcast the first target block to other consensus nodes so that other consensus nodes can reach a consensus on whether to put the first target block on the chain. After receiving the consensus of other consensus nodes, the first target block will be put on the chain to the blockchain network. After the first target block is put on the chain, the target consensus node will delete the transactions to be put on the chain that are packaged into the first target block from its own target transaction queue and the corresponding transaction queue to be put on the chain.

[0147] Through the above steps 310-340, the embodiment of the present disclosure obtains multiple queues of transactions to be chained maintained by the target consensus node, and saves the multiple transactions to be chained received by the target consensus node in the form of queues, thereby improving the storage orderliness of the transactions to be chained. Then, from the target transaction queue corresponding to the target consensus node in the multiple queues of transactions to be chained, the transactions to be chained are preferentially taken out and packaged into the first target block, so that the transactions to be chained in the target transaction queue are preferentially packaged and chained. Furthermore, if the size of the first target block is still less than the first threshold after the target transaction queue is emptied, a filtered transaction queue whose queue length exceeds the second threshold is screened out from the to-be-linked transaction queues corresponding to other consensus nodes among the multiple consensus nodes; the to-be-linked transactions are taken out from the filtered transaction queue and added to the first target block. Based on the node processing capacity of the target consensus node, after the to-be-linked transactions in the target transaction queue are preferentially processed, if there is still free space in the first target block, the to-be-linked transactions in the filtered transaction queue with a longer queue length are added to the first target block, so that the to-be-linked transactions in the to-be-linked transaction queues corresponding to other consensus nodes with higher loads can be processed as soon as possible, which is conducive to improving transaction processing efficiency, and can also alleviate the block production pressure of consensus nodes with more to-be-processed transactions, thereby reducing block production delays and improving block production efficiency.

[0148] The above is a general description of steps 310 to 340. Since step 330 has been described in detail in the above general description, the specific implementation of steps 310, 320, and 340 will be described in detail below.

[0149] Detailed description of step 310

[0150] In step 310, multiple transaction queues to be uploaded to the chain maintained by the target consensus node are obtained.

[0151] In the specific implementation of this embodiment, when the target consensus node maintains multiple queues of transactions to be chained, it can first classify the transactions to be chained according to the transaction sources of each transaction to be chained, and obtain a set of transactions to be chained consisting of the transactions to be chained of each consensus node. Then, for each set of transactions to be chained, sort the transactions to be chained in the set of transactions to be chained in a certain order to obtain multiple queues of transactions to be chained.

[0152] For example, the transactions to be on-chain in the transaction set to be on-chain are sorted according to timestamps to obtain multiple transaction queues to be on-chain. In each transaction queue to be on-chain, transactions to be on-chain with earlier timestamps are arranged at the front, and transactions to be on-chain with later timestamps are arranged at the back.

[0153] Among them, the timestamp of the transaction to be on-chain is used to indicate the time point when each consensus node receives the transaction to be on-chain from the client.

[0154] Combine the following Figure 4 , Figure 5 and Figure 6 The process of generating multiple queues of transactions to be uploaded to the chain is described in detail.

[0155] Please refer to Figure 4 In one embodiment, the process of generating multiple queues of transactions to be uploaded includes but is not limited to the following steps 410-420:

[0156] Step 410: In response to receiving a transaction to be uploaded from the client, the transaction to be uploaded received from the client is saved in a target transaction queue corresponding to the target consensus node, and the transaction to be uploaded is forwarded to other consensus nodes;

[0157] Step 420: In response to receiving transactions to be uploaded from other consensus nodes, the transactions to be uploaded received from other consensus nodes are stored in the transaction queues to be uploaded corresponding to the other consensus nodes, without forwarding the transactions to be uploaded.

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

[0159] In step 410, in response to receiving a transaction to be on-chain from the client, the transaction to be on-chain received from the client is saved in a target transaction queue corresponding to the target consensus node, and the transaction to be on-chain is forwarded to other consensus nodes.

[0160] In the specific implementation of this embodiment, when the object wants to record a transaction on the blockchain network, it often sends the transaction to the consensus node on the blockchain network through the client, and the consensus node packages the transaction into a block to put the transaction on the chain. Based on this, the blockchain network server can respond to receiving the transaction to be on the chain from the client, save the transaction to be on the chain received from the client in the target transaction queue corresponding to the target consensus node, and realize the preservation of the transaction to be on the chain; at the same time, the target consensus node also forwards the transaction to be on the chain to other consensus nodes, and realizes the broadcast of the transaction to be on the chain.

[0161] like Figure 5As shown, it is a schematic diagram of the improvement of the transaction pool of the target consensus node A in the embodiment of the present disclosure. In the related art, the multiple transactions to be chained in the transaction pool of the target consensus node A are often freely stored and disordered, which is not conducive to the transaction management of the transactions to be chained. Based on this, the embodiment of the present disclosure improves the transaction pool of the target consensus node A, and divides the multiple transactions to be chained in the transaction pool of the target consensus node A into multiple transaction queues to be chained. Specifically, the transactions to be chained belonging to the same source in the transaction pool of the target consensus node A are saved in the same queue. Among them, the target transaction queue stores the transactions to be chained received by the target consensus node A from the client, and the target transaction queue includes transactions to be chained 1, transactions to be chained 5, transactions to be chained 11, and transactions to be chained 18. The transaction queue B to be chained stores the transactions to be chained received by the target consensus node A from the consensus node B, and the transaction queue B to be chained includes transactions to be chained 2, transactions to be chained 3, transactions to be chained 8, transactions to be chained 9, and transactions to be chained 16. By analogy, multiple queues of transactions to be chained are maintained in the transaction pool of the target consensus node A. Further, when the target consensus node A receives a new transaction 19 to be chained from the client, the transaction 19 to be chained is saved in the target transaction queue.

[0162] In step 420, in response to receiving transactions to be on-chain from other consensus nodes, the transactions to be on-chain received from other consensus nodes are saved in the queues of transactions to be on-chain corresponding to the other consensus nodes, without forwarding the transactions to be on-chain.

[0163] In the blockchain network, each consensus node often broadcasts the transactions it receives from the client to each other. If each consensus node continues to forward the pending transactions received from other consensus nodes, the same pending transaction will often be sent repeatedly, causing network congestion.

[0164] Based on this, when this embodiment is implemented, the target consensus node will respond to receiving transactions to be put on the chain from other consensus nodes, save the transactions to be put on the chain received from other consensus nodes in the corresponding transaction queues to be put on the chain of other consensus nodes, and save the transactions to be put on the chain received from different consensus nodes in different transaction queues to be put on the chain, so as to achieve orderly storage of transactions to be put on the chain. In addition, the target consensus node will not continue to forward the transactions to be put on the chain received from other consensus nodes, which can reduce the possibility of the same transaction to be put on the chain being sent repeatedly.

[0165] like Figure 6As shown, it is a schematic diagram of the improvement of the transaction broadcast process in the embodiment of the present disclosure. In the related art, each consensus node often broadcasts the transactions received from the client to each other. Specifically, when the object M sends the transaction to the target consensus node A through the client, the target consensus node A will forward the transaction received from the client to consensus node B, consensus node C, and consensus node D respectively. Further, after consensus node B, consensus node C, and consensus node D receive the transaction, they will forward the transaction to the other two consensus nodes, which will cause the transaction to be forwarded repeatedly. For example, consensus node C receives the transaction forwarded by the target consensus node A, consensus node B, and consensus node D, resulting in three forwardings of the same transaction. Compared with the related art, in the embodiment of the present disclosure, each consensus node often broadcasts the transaction received from the client, but does not broadcast the transaction received from other consensus nodes. Specifically, when the object M sends the transaction to the target consensus node A through the client, the target consensus node A will forward the transaction received from the client to consensus node B, consensus node C, and consensus node D respectively. Consensus node B, consensus node C, and consensus node D no longer forward this transaction. For example, consensus node C only receives transactions forwarded by the target consensus node. It can be seen that compared with the related art, the transaction broadcasting method of the embodiment of the present disclosure does not broadcast the same transaction repeatedly, and the transaction broadcast volume is significantly reduced.

[0166] Through the above steps 410-420, in the disclosed embodiment, each consensus node in the blockchain network will save the pending transactions received from the client in its own target transaction queue, and save the pending transactions received from other consensus nodes in the corresponding pending transaction queues, which can classify and store the pending transactions according to the source of the pending transactions, thereby improving the storage standardization of the pending transactions. At the same time, the consensus node will send the pending transactions received from the client to other consensus nodes, without forwarding the pending transactions received by other consensus nodes, which can effectively reduce the transaction broadcast volume and reduce the possibility of the same pending transaction being sent repeatedly, thereby alleviating network congestion and improving transaction processing efficiency.

[0167] Detailed description of step 320

[0168] In step 320, the transactions to be chained are preferentially taken out from the target transaction queue corresponding to the target consensus node in the multiple transaction queues to be chained and packaged into the first target block.

[0169] In the specific implementation of this embodiment, when taking out the transactions to be chained from the target transaction queue corresponding to the target consensus node in the multiple transaction queues to be chained, and packaging them into the first target block, a certain number of transactions to be chained can be randomly selected from the target transaction queue and packaged into the first target block, or a certain number of transactions to be chained can be selected from the target transaction queue based on a predetermined screening method and packaged into the first target block, without limitation.

[0170] Since a certain number of transactions to be uploaded are randomly selected from the target transaction queue and packaged into the first target block, the transactions to be uploaded are often packaged in a later round of block generation, or more important and urgent transactions to be uploaded are not packaged and uploaded as quickly as possible. Based on this, the disclosed embodiment provides a solution for selecting transactions to be uploaded and packaging them into the first target block based on the timestamps and real-time performance of the transactions to be uploaded, which can improve the rationality of taking out transactions to be uploaded, and thus improve transaction processing efficiency.

[0171] It should be noted that the real-time nature of transactions to be uploaded to the blockchain is used to indicate the urgency of uploading transactions to the blockchain.

[0172] Combine the following Figure 7A-7B The process of preferentially taking out transactions to be uploaded from the target transaction queue and packaging them into the first target block is described in detail.

[0173] In one embodiment, the transactions to be uploaded are taken out according to the timestamps of each transaction to be uploaded in the target transaction queue and packaged into the first target block. Specifically, the timestamps of each transaction to be uploaded are determined; then, the transactions to be uploaded are sorted according to the time of the timestamps. Finally, according to the first threshold, the transactions to be uploaded that are ranked first in the sorting are selected and packaged into the first target block first.

[0174] like Fig. 7A As shown, the first threshold is 4, and there are 8 pending transactions on the target transaction queue. These 8 pending transactions are sorted in the order of timestamps: pending transaction 1, pending transaction 5, pending transaction 11, pending transaction 2, pending transaction 4, pending transaction 15, pending transaction 22, pending transaction 18. Based on this, the 4 pending transactions with earlier timestamps (i.e., pending transaction 1, pending transaction 5, pending transaction 11, pending transaction 2) are packaged into the first target block.

[0175] Through the above method, the embodiment of the present disclosure selects the transactions to be uploaded to the chain for priority packaging according to the timestamps of the transactions to be uploaded to the chain, and based on the principle of "first in, first out", the transactions to be uploaded to the chain with an earlier generation time are preferentially packaged into the first target block, and then preferentially uploaded to the blockchain, thereby improving the timeliness and efficiency of transaction processing.

[0176] In another embodiment, the transactions to be chained are taken out according to the real-time scores of each transaction to be chained in the target transaction queue and packaged into the first target block. Specifically, the number of resource transfers associated with each transaction to be chained is first determined; then, the real-time score of each transaction to be chained is determined based on the number of resource transfers. Further, the transactions to be chained are sorted according to the size of the real-time score. Finally, according to the first threshold, in the sorting, the transactions to be chained that are ranked in the front predetermined ranking are selected and packaged into the first target block first.

[0177] Among them, the number of resource transfers associated with the transaction to be put on the chain refers to the total number of resources transferred represented by the transaction to be put on the chain. When determining the real-time score of each transaction to be put on the chain based on the number of resource transfers, the number of resource transfers can be substituted into a preset function, and the output of the preset function can be used as the real-time score. The preset function is an increasing function with the number of resource transfers as the independent variable and the real-time score as the dependent variable. The larger the number of resource transfers, the higher the real-time score of the transaction to be put on the chain.

[0178] like Figure 7B As shown, the first threshold is 4, and there are 8 transactions to be uploaded to the chain in the target transaction queue. These 8 transactions to be uploaded to the chain are sorted in order of the size of the real-time scores. Specifically, the real-time score of transaction 5 to be on the chain is 88, and transaction 5 to be on the chain ranks first; the real-time score of transaction 1 to be on the chain is 77, and transaction 1 to be on the chain ranks second; the real-time score of transaction 2 to be on the chain is 66, and transaction 2 to be on the chain ranks third; the real-time score of transaction 22 to be on the chain is 57, and transaction 22 to be on the chain ranks fourth; the real-time score of transaction 11 to be on the chain is 50, and transaction 5 to be on the chain ranks fifth; the real-time score of transaction 11 to be on the chain is 50, and transaction 5 to be on the chain ranks fifth; the real-time score of transaction 15 to be on the chain is 48, and transaction 15 to be on the chain ranks sixth; the real-time score of transaction 4 to be on the chain is 44, and transaction 4 to be on the chain ranks seventh; the real-time score of transaction 18 to be on the chain is 32, and transaction 18 to be on the chain ranks sixth. Based on this, the four transactions to be on-chain with larger real-time scores (i.e., transaction to be on-chain 5, transaction to be on-chain 1, transaction to be on-chain 2, and transaction to be on-chain 22) are packaged into the first target block.

[0179] Through the above method, the embodiment of the present disclosure selects the transactions to be uploaded to the chain for priority packaging according to the real-time scores of the transactions to be uploaded to the chain, and based on the principle of "the higher the real-time, the first to be packaged", the transactions to be uploaded to the chain with higher real-time performance are preferentially packaged in the first target block, and then preferentially uploaded to the blockchain, thereby improving the timeliness and efficiency of transaction processing.

[0180] Detailed description of step 340

[0181] In step 340, the transactions to be uploaded are taken from the filtered transaction queue and added to the first target block.

[0182] When this embodiment is implemented, a certain number of transactions to be uploaded may be randomly taken from multiple filtered transaction queues and added to the first target block until the size of the first target block reaches a first threshold.

[0183] For example, when the filtered transaction queues include filtered transaction queue A, filtered transaction queue B, and filtered transaction queue C, when the difference between the size of the first target block and the first threshold is 4, one transaction to be uploaded to the chain is randomly taken from the filtered transaction queue A and the filtered transaction queue B, and added to the first target block; two transactions to be uploaded to the chain are randomly taken from the filtered transaction queue C, and added to the first target block, so that the size of the first target block reaches the first threshold.

[0184] Since a certain number of transactions to be on-chain are randomly taken out from multiple post-screening transaction queues to be added to the first target block, it often causes the problem that there are still a large number of transactions to be on-chain in some post-screening transaction queues, which is not conducive to balancing the transaction processing pressure of each consensus node. Based on this, the embodiment of the present disclosure provides a scheme for taking out transactions to be on-chain from each post-screening transaction queue based on the queue length of the post-screening transaction queue, which can make the transactions to be on-chain in the post-screening transaction queue with a larger queue length be taken out first, which is conducive to reducing the transaction processing pressure of the consensus node corresponding to the post-screening transaction queue with a larger congestion degree, reducing the block delay of the consensus node with a larger congestion degree, and improving the block efficiency.

[0185] Combine the following Figure 8 , Fig. 9 The process of taking out the transactions to be uploaded from the filtered transaction queue and adding them to the first target block is described in detail.

[0186] Please refer to Figure 8 In one embodiment, the process of taking out the to-be-uploaded transactions from the filtered transaction queue and adding them to the first target block includes but is not limited to the following steps 810-820:

[0187] Step 810: for each filtered transaction queue, determine the first difference between the queue length and the second threshold, and filter out the first difference filtered transactions to be uploaded to the chain with the earliest timestamp in the filtered transaction queue;

[0188] Step 820: perform a first sort on the multiple filtered transaction queues in descending order of queue length, and take out filtered transactions to be on-chain from the filtered transaction queues according to the first sort to fill the first target block until the size of the first target block reaches the first threshold.

[0189] Steps 810-820 are described in detail below.

[0190] In step 810, for each filtered transaction queue, the first difference between the queue length and the second threshold is determined, and the first difference filtered transactions to be uploaded to the chain with the earliest timestamp are filtered out from the filtered transaction queue.

[0191] The first difference is used to indicate the extent to which the queue length of each post-screening transaction queue exceeds the second threshold. The larger the first difference, the more transactions to be uploaded to the post-screening transaction queue, and the higher the congestion level of the post-screening transaction queue.

[0192] In the specific implementation of this embodiment, firstly, the queue length of each filtered transaction queue is subtracted from the second threshold to obtain the first difference between the queue length and the second threshold. Then, according to the first difference and the timestamp of each transaction to be uploaded, the transactions to be uploaded in the filtered transaction queue are filtered to obtain the first difference transaction to be uploaded with the earliest timestamp, and the filtered transactions to be uploaded are used as the filtered transactions to be uploaded.

[0193] In step 820, a plurality of filtered transaction queues are sorted in a first order according to the queue length from high to low, and filtered transactions to be on-chain are taken out from the filtered transaction queues according to the first order to fill the first target block until the size of the first target block reaches the first threshold.

[0194] In the specific implementation of this embodiment, since the longer the queue length is, the more transactions to be on the chain in the filtered transaction queue, the higher the demand for other consensus nodes to help with a part of the transactions to be on the chain. Based on this, firstly, a plurality of filtered transaction queues are sorted in the order of queue length from high to low. In the first sorting, the filtered transaction queues with larger queue lengths are arranged in the front position, and the filtered transaction queues with smaller queue lengths are arranged in the back position. Then, from the filtered transaction queue ranked first in the first sorting, multiple filtered transactions to be on the chain are taken out in sequence according to the order of timestamps and filled into the first target block. If the size of the first target block is still less than the first threshold after all the filtered transactions to be on the chain in the first filtered transaction queue are taken out, then multiple filtered transactions to be on the chain are taken out in sequence according to the order of timestamps and filled into the first target block from the filtered transaction queue ranked second in the first sorting. By analogy, according to the first sorting, multiple filtered transactions to be chained are taken out from multiple filtered transaction queues in the order of timestamps and filled into the first target block until the size of the first target block reaches the first threshold.

[0195] like Fig. 9As shown, the first threshold is 7 and the second threshold is 4. First, the to-be-chained transactions 1, 5, 11, and 18 in the target transaction queue are packed into the first target block. At this time, after the target transaction queue is empty, the size of the first target block is still less than the first threshold, and the to-be-chained transaction queues of other consensus nodes are screened to obtain the to-be-chained transaction queues B and C whose queue lengths are greater than the second threshold. Further, it is determined that the first difference between the to-be-chained transaction queue B and the second threshold is 1; and it is determined that the first difference between the to-be-chained transaction queue C and the second threshold is 2. Based on this, it is necessary to first pack the two screened to-be-chained transactions with the earliest timestamps in the to-be-chained transaction queue C into the first target block, so the to-be-chained transactions 4 and 6 in the to-be-chained transaction queue C are packed into the first target block. Further, after the to-be-chained transactions 4 and 6 are packed into the first target block, the size of the first target block is still less than the first threshold. At this time, it is necessary to package the filtered transaction to be chained with the earliest timestamp in the transaction queue B to be chained into the first target block. Therefore, the transaction to be chained 2 in the transaction queue B to be chained is packaged into the first target block so that the size of the first target block reaches the first threshold.

[0196] Through the above steps 810-820, the embodiment of the present disclosure takes out the to-be-linked transactions from each filtered transaction queue based on the queue length of the filtered transaction queue, performs a first sort on each filtered transaction queue based on the first difference between the queue length and the second threshold, and takes out the to-be-linked transactions according to the first sort, so that the to-be-linked transactions of the filtered transaction queue with a larger queue length can be taken out first, and after the first difference to-be-linked transactions of the filtered transaction queue with a larger queue length are taken out, the to-be-linked transactions are taken out from the filtered transaction queue with a relatively smaller queue length, which is beneficial to reducing the transaction processing pressure of the consensus node corresponding to the filtered transaction queue with a larger congestion, thereby reducing the block delay of the consensus node with a larger congestion, and improving the block efficiency.

[0197] Since each consensus node has different transaction processing capabilities, there is often a consensus node whose queue length of pending chained transactions is not the longest, but whose block generation efficiency is lower than that of a consensus node whose queue length of pending chained transactions is longer. If the pending chained transactions are taken out from the filtered transaction queue according to the queue length, it is often impossible to effectively improve the block generation efficiency of the consensus node with poor processing capabilities. Based on this, the disclosed embodiment provides a scheme for each consensus node to mark the pending chained transactions that need to be allocated to other consensus nodes, and to take out the pending chained transactions from the filtered transaction queue according to the number of marked pending chained transactions. This scheme can effectively give priority to adding the pending chained transactions of the consensus node with poor processing capabilities to the first target block, reduce the block generation delay of the consensus node with poor processing capabilities, and improve the block generation efficiency of the node.

[0198] Combine the following Fig.10 The process of taking out the transactions to be uploaded from the filtered transaction queue and adding them to the first target block is described in detail.

[0199] Please refer to Fig.10 In one embodiment, the process of taking out the to-be-uploaded transactions from the filtered transaction queue and adding them to the first target block includes but is not limited to the following steps 1010-1020:

[0200] Step 1010: for each filtered transaction queue, determine the transactions marked to be uploaded to the chain in the filtered transaction queue;

[0201] Step 1020: perform a second sort on the multiple filtered transaction queues in the order of the number of marked transactions to be chained from high to low, and take out the marked transactions to be chained from the filtered transaction queues according to the second sort to fill the first target block until the size of the first target block reaches the first threshold.

[0202] Steps 1010 - 1020 are described in detail below.

[0203] In step 1010, for each filtered transaction queue, the marked transactions to be chained in the filtered transaction queue are determined.

[0204] Marked transactions to be put on the chain refer to transactions to be put on the chain that are marked according to the preset marking principles in each filtered transaction queue.

[0205] In the specific implementation of this embodiment, for each filtered transaction queue, the mark of each to-be-chained transaction in the filtered transaction queue is queried; and the to-be-chained transaction marked as allocated to other consensus nodes is used as the marked to-be-chained transaction.

[0206] In step 1020, a plurality of filtered transaction queues are sorted for a second time in descending order of the number of transactions marked for chaining, and the marked transactions to be chained are taken out from the filtered transaction queues according to the second sorting to fill the first target block until the size of the first target block reaches the first threshold.

[0207] In the specific implementation of this embodiment, since the more the number of marked transactions to be on the chain in the filtered transaction queue is, the more transactions to be on the chain in the filtered transaction queue is, and the higher the demand for other consensus nodes to help a part of the transactions to be on the chain is. Based on this, firstly, the multiple filtered transaction queues are sorted in the order of the number of marked transactions to be on the chain from high to low. In the second sorting, the filtered transaction queues with a large number of marked transactions to be on the chain are arranged in the front position, and the filtered transaction queues with a small number of marked transactions to be on the chain are arranged in the back position. Then, first, from the first filtered transaction queue in the second sorting, in the order of the timestamps of the marked transactions to be on the chain, multiple marked transactions to be on the chain are taken out in sequence to fill the first target block. If the size of the first target block is still less than the first threshold after all the marked transactions to be on the chain in the first filtered transaction queue are taken out, then continue to take out multiple marked transactions to be on the chain from the second filtered transaction queue in the second sorting in the order of the timestamps of the marked transactions to be on the chain to fill the first target block. By analogy, according to the second sorting, multiple marked transactions to be chained are taken out from multiple filtered transaction queues in the order of the timestamps of the marked transactions to be chained, and filled into the first target block until the size of the first target block reaches the first threshold.

[0208] Through the above steps 1010-1020, the embodiment of the present disclosure enables each consensus node to mark the transactions to be chained that need to be allocated to other consensus nodes, and performs a second sort on each filtered transaction queue according to the number of marked transactions to be chained. According to the second sort, the marked transactions to be chained are taken out from each filtered transaction queue in turn, which can reasonably determine the transaction retrieval order of the filtered transaction queue and reasonably select the transactions to be chained that need to be taken out, which can save the screening time of the transactions to be chained, effectively give priority to adding the transactions to be chained of the consensus nodes with poor processing capabilities to the first target block, reduce the block generation delay of the consensus nodes with poor processing capabilities, and improve the block generation efficiency of the nodes.

[0209] It should be noted that each consensus node packages the transactions to be chained into blocks and chains them to the blockchain network in a certain order. When the queue lengths of the filtered transaction queues are the same, or the number of marked transactions to be chained in the filtered transaction queues is the same, the filtered transactions to be chained can be taken out from the filtered transaction queues that are first produced in the order of blocks to fill the first target block. Then, according to the relationship between the size of the first target block and the first threshold, when the size of the first target block is still less than the first threshold, the filtered transactions to be chained are taken out from the filtered transaction queues that are produced later to fill the first target block.

[0210] Please refer to Fig.11In some embodiments, the transaction to be on-chain is marked by a marking consensus node among the plurality of consensus nodes in the following manner:

[0211] Step 1110: Obtain a second difference between the number of transactions to be uploaded to the marked consensus node and the first threshold;

[0212] Step 1120: Evenly distribute the second-worst transaction to be uploaded with the earliest timestamp among the transactions to be uploaded to the marked consensus node to other consensus nodes, and mark the distributed transactions to be uploaded to the chain.

[0213] Steps 1110 - 1120 are described in detail below.

[0214] The marked consensus node refers to a consensus node in the blockchain network whose number of transactions to be uploaded is greater than the second threshold.

[0215] In step 1110, the second difference between the number of transactions to be on-chain of the marked consensus node and the first threshold is obtained.

[0216] The number of pending transactions on the chain for the marked consensus node refers to the total number of pending transactions on the chain for the marked consensus node.

[0217] The second difference is used to indicate the extent to which the number of transactions to be uploaded to the chain of each marked consensus node exceeds the first threshold. The larger the second difference, the more transactions to be uploaded to the chain of the marked consensus node, and the higher the congestion of the filtered transaction queue corresponding to the marked consensus node.

[0218] In the specific implementation of this embodiment, firstly, the transactions to be put on the chain of the marked consensus node are counted to obtain the number of transactions to be put on the chain of the marked consensus node. Then, the number of transactions to be put on the chain is subtracted from the first threshold to obtain the second difference.

[0219] For example, the number of transactions to be uploaded to the marked consensus node is 10, and the first threshold is 6, then the second difference is 10-6=4.

[0220] In step 1120, the second-worst transaction to be uploaded with the earliest timestamp among the transactions to be uploaded to the marked consensus node is evenly distributed to other consensus nodes, and the distributed transactions to be uploaded are marked.

[0221] In the specific implementation of this embodiment, first, according to the timestamps of the transactions to be chained that mark the consensus nodes, the second difference transactions to be chained with the earliest timestamps are screened out; then, consensus nodes whose queue lengths of the transaction queues to be chained are less than the second threshold are screened out from multiple consensus nodes; the second difference transactions to be chained are evenly distributed to the consensus nodes whose queue lengths of the transaction queues to be chained are less than the second threshold, and the distributed transactions to be chained are marked.

[0222] Furthermore, when the second difference in transactions to be on-chain is less than the consensus nodes whose queue length of the transaction queue to be on-chain is less than the second threshold, several consensus nodes whose queue length of the transaction queue to be on-chain is less than the second threshold can be randomly selected as target allocation consensus nodes. Then, the second difference in transactions to be on-chain are evenly allocated to the target allocation consensus nodes.

[0223] For example, if there are 10 pending transactions to be chained that need to be allocated to other consensus nodes in the marked consensus node, but there are 12 consensus nodes whose queue length of the pending transaction queue is less than the second threshold, then 10 are randomly selected from the consensus nodes whose queue length of the pending transaction queue is less than the second threshold as target allocation consensus nodes, and one pending transaction is allocated to each target allocation consensus node; or, 5 are randomly selected from the consensus nodes whose queue length of the pending transaction queue is less than the second threshold as target allocation consensus nodes, and 2 pending transactions are allocated to each target allocation consensus node.

[0224] Furthermore, if the number of transactions to be uploaded to the chain of the target assigned consensus node exceeds the second threshold after the target assigned consensus node is assigned a certain number of transactions to be uploaded to the chain, the transactions to be uploaded to the chain assigned to the target assigned consensus node will be reallocated to other consensus nodes, so that the number of transactions to be uploaded to the chain of the target assigned consensus node does not exceed the second threshold.

[0225] For example, the first threshold is 6, and the second threshold is 6. The number of pending transactions of the marked consensus node A is 10. The marked consensus node A plans to allocate 4 transactions to consensus nodes B and consensus node C, whose queue length of pending transactions is less than the second threshold, on average, that is, consensus nodes B and consensus nodes C are each allocated 2 pending transactions. However, consensus node B has 5 pending transactions, and consensus node C has 3 pending transactions. If 2 pending transactions are allocated to consensus node B, the total number of pending transactions of consensus node B will become 7, which will cause transaction congestion of consensus node B. Based on this, one pending transaction originally allocated to consensus node B is reallocated to consensus node C, so that through the allocation of pending transactions, the pending transactions of the marked consensus node A become 6, the pending transactions of consensus node B become 6, and the pending transactions of consensus node C become 6, so as to achieve the purpose of load balancing between nodes.

[0226] like Fig.12As shown, the first threshold is 6 and the second threshold is 8. There are 10 transactions to be chained in the transaction queue of the marked consensus node. In the transaction queue, the 10 transactions to be chained are arranged in the order of the early and late timestamps. First, the second difference between the number of transactions to be chained of the marked consensus node and the first threshold is calculated to be 10-6=4. Then, the top 4 transactions to be chained in the transaction queue of the marked consensus node are used as marked transactions to be chained. Among them, the marked transactions to be chained include transactions to be chained 1, transactions to be chained 2, transactions to be chained 3, and transactions to be chained 4. Further, it is determined that the 4 marked transactions to be chained are evenly distributed to consensus node 1, consensus node 2, consensus node 3, and consensus node 11. Finally, transaction 1 to be chained is assigned to consensus node 1; transaction 2 to be chained is assigned to consensus node 2; transaction 3 to be chained is assigned to consensus node 3; transaction 4 to be chained is assigned to consensus node 11, so that each consensus node is evenly allocated to a transaction to be chained.

[0227] Through the above steps 1110-1120, the embodiment of the present disclosure distributes multiple transactions to be chained with the earliest timestamps in the marked consensus node to other consensus nodes with processing capabilities according to the principle of average distribution, so that other consensus nodes can help process a part of the transactions to be chained of the marked consensus node, thereby improving the timeliness of processing the transactions to be chained with earlier timestamps, achieving load balancing among the consensus nodes, and effectively improving the processing efficiency of the transactions to be chained.

[0228] Please refer to Fig.13 In some other embodiments, the transaction to be on-chain is marked by a marking consensus node among the plurality of consensus nodes in the following manner:

[0229] Step 1310: Obtain a second difference between the number of transactions to be uploaded to the marked consensus node and the first threshold;

[0230] Step 1320: Obtain the node processing capacity and credit of each other consensus node;

[0231] Step 1330: Determine the allocation tendency of each other consensus node based on the node processing capacity and credit;

[0232] Step 1340: distribute the second-worst transaction to be uploaded to the chain with the earliest timestamp among the transactions to be uploaded to the chain of the marked consensus node to other consensus nodes according to the distribution tendency of each other consensus node, and mark the distributed transaction to be uploaded to the chain.

[0233] Steps 1310 - 1340 are described in detail below.

[0234] In step 1310, the specific implementation process of obtaining the second difference between the number of transactions to be on-chain of the marked consensus node and the first threshold is similar to the specific implementation process of the above step 1110. To save space, it will not be repeated.

[0235] In step 1320, the node processing capacity and credit of each other consensus node are obtained.

[0236] The node processing capacity is used to indicate the number of pending transactions that the target block can accommodate after the consensus node packages its pending transactions into the target block in each block production round.

[0237] For example, in a certain block round, the number of transactions to be uploaded to the chain of consensus node 1 itself is 8. After packaging the 8 transactions to be uploaded to the chain into the target block, the target block can still accommodate 2 transactions to be uploaded to the chain. Then the node processing capacity of consensus node 1 is 2 / (2+8)=0.2.

[0238] The credit of a consensus node is used to reflect whether the consensus node produces blocks on time during consensus, the authenticity of the messages broadcast by the consensus node, etc. The higher the credit of a consensus node, the higher the authenticity of the messages broadcast by the consensus node.

[0239] In the specific implementation of this embodiment, for each other consensus node, first determine the number of transactions to be on the chain that the target block can accommodate after the consensus node packs its own transactions to be on the chain into the target block in each block round. Then, based on the total number of transactions to be on the chain that the target block is allowed to accommodate and the number of transactions to be on the chain that the target block can accommodate after packing its own transactions to be on the chain, calculate the node processing capacity of the consensus node in each block round. Finally, average the node processing capacity of all block rounds to obtain the final node processing capacity of the consensus node.

[0240] Furthermore, for each other consensus node, the number of times the consensus node generates blocks on time in all block generation rounds is counted, and the number of on-time blocks is divided by the total number of block generation rounds to obtain the on-time block generation credit of the consensus node, and the on-time block generation credit is used as the credit of the consensus node.

[0241] In step 1330, the allocation preference of each other consensus node is determined based on the node processing capacity and credibility.

[0242] The allocation tendency is used to characterize the degree to which the marked consensus node tends to allocate transactions to be on-chain to a certain consensus node. If the marked consensus node has a higher allocation tendency to a certain consensus node, it means that the marked consensus node is more willing to allocate transactions to be on-chain to that consensus node.

[0243] In the specific implementation of this embodiment, the allocation tendency of each other consensus node can be determined only based on the node processing capacity; the allocation tendency of each other consensus node can also be determined only based on the credit; the allocation tendency of each other consensus node can also be determined based on the combination of node processing capacity and credit, without limitation.

[0244] In one embodiment, the allocation tendency of each other consensus node is determined based only on the node processing capacity. Specifically, the node processing capacity of other consensus nodes corresponding to multiple filtered transaction queues is first summed to obtain the total node processing capacity, and then, for other consensus nodes corresponding to each filtered transaction queue, the node processing capacity of the consensus node and the total node processing capacity are divided to obtain the division result, and the division result is converted into a percentage system to obtain the allocation tendency of the marked consensus node to this consensus node.

[0245] For example, other consensus nodes corresponding to multiple filtered transaction queues include consensus node 1, consensus node 3, and consensus node 15. The node processing capacity of consensus node 1 is 0.3, the node processing capacity of consensus node 3 is 0.2, and the node processing capacity of consensus node 15 is 0.1. Then, the allocation tendency of consensus node 1 is [0.3 / (0.1+0.2+0.3)]×100=50; the allocation tendency of consensus node 3 is [0.2 / (0.1+0.2+0.3)]×100=33; the allocation tendency of consensus node 15 is [0.1 / (0.1+0.2+0.3)]×100=17.

[0246] This method calculates the allocation tendency of the marked consensus nodes to each consensus node based on the node processing capacity of each consensus node, which can ensure that the transactions to be uploaded to the chain are allocated to the consensus nodes with good node processing capacity as much as possible, thereby improving the efficiency and security of block generation.

[0247] In another embodiment, the allocation tendency of each other consensus node is determined based only on the credit. Specifically, the specific implementation process of determining the allocation tendency of each other consensus node based only on the credit is similar to the specific implementation process of determining the allocation tendency of each other consensus node based only on the node processing capacity. To save space, it will not be repeated.

[0248] This method calculates the allocation tendency of the marked consensus nodes to each consensus node based on the credit of each consensus node, which can ensure that the transactions to be on the chain are allocated to the consensus nodes with high credit as much as possible, thereby improving the efficiency and security of block generation.

[0249] In another embodiment, the allocation tendency of each other consensus node is determined based on a combination of node processing capacity and credit. Specifically, first, a first tendency of each other consensus node is calculated based on the node processing capacity; then, a second tendency of each other consensus node is calculated based on the credit. Finally, based on the first tendency and the second tendency, the allocation tendency of each other consensus node is determined.

[0250] The specific implementation process of calculating the first tendency of each other consensus node based on the node processing capacity and the second tendency of each other consensus node based on the credit is similar to the specific implementation process of determining the allocation tendency of each other consensus node based on the node processing capacity. To save space, it will not be repeated.

[0251] Furthermore, when determining the allocation tendency of each other consensus node based on the first tendency and the second tendency, first, for each consensus node, determine the first weight of the first tendency and the second weight of the second tendency, wherein the first weight is used to characterize the importance of the node processing capacity in the allocation of transactions to be put on the chain; the second weight is used to characterize the importance of the credit in the allocation of transactions to be put on the chain. Then, multiply the first weight and the first tendency to obtain the first weighted tendency; multiply the second weight and the second tendency to obtain the second weighted tendency. Finally, add the first weighted tendency and the second weighted tendency to obtain the allocation tendency of the consensus node.

[0252] This method calculates the allocation tendency of the marked consensus nodes to each consensus node based on the node processing capacity and credit of each consensus node, so that the transactions to be on the chain can be allocated to the consensus nodes with good node processing capacity and high credit as much as possible, thereby improving the rationality of transaction allocation.

[0253] like Fig.14A As shown, based on the node processing capacity and credit of each node, the allocation tendency of each consensus node is calculated. Among them, the allocation tendency of consensus node 1 is 55; the allocation tendency of consensus node 2 is 10; the allocation tendency of consensus node 8 is 3; the allocation tendency of consensus node 11 is 9; and the allocation tendency of consensus node 15 is 20.

[0254] In step 1340, the second-worst transaction to be on-chain with the earliest timestamp among the transactions to be on-chain of the marked consensus node is allocated to other consensus nodes according to the allocation tendency of each other consensus node, and the allocated transaction to be on-chain is marked.

[0255] In the specific implementation of this embodiment, first, according to the timestamps of the transactions to be on the chain of the marked consensus node, the second-worst transaction to be on the chain with the earliest timestamp is screened out. Then, according to the allocation tendency of each other consensus node, the transactions to be on the chain are first allocated to the consensus node with the highest allocation tendency. When the number of transactions to be on the chain of the consensus node with the highest allocation tendency reaches the upper limit, the transactions to be on the chain that need to be allocated but have not been allocated will continue to be allocated to the consensus node with the second highest allocation tendency, and so on, until the second-worst transaction to be on the chain is allocated, and the allocated transactions to be on the chain are marked.

[0256] like Fig. 14B As shown, the first threshold is 6 and the second threshold is 8. There are 10 transactions to be chained in the transaction queue of the marked consensus node. In the transaction queue, the 10 transactions to be chained are arranged in the order of the early and late timestamps. First, the second difference between the number of transactions to be chained of the marked consensus node and the first threshold is calculated to be 10-6=4. Next, the top 4 transactions to be chained in the transaction queue of the marked consensus node are used as marked transactions to be chained. Among them, the marked transactions to be chained include transactions to be chained 1, transactions to be chained 2, transactions to be chained 3, and transactions to be chained 4. Further, the allocation tendencies of each consensus node are compared, and the three consensus nodes with higher allocation tendencies are taken to obtain consensus nodes 1, consensus nodes 2, and consensus nodes 15. Finally, transactions to be chained 1 and transactions to be chained 2 are assigned to consensus node 1; transactions to be chained 3 are assigned to consensus node 15; and transactions to be chained 4 are assigned to consensus node 2.

[0257] Through the above steps 1310-1340, the embodiment of the present disclosure calculates the allocation tendency of the marked consensus node to each consensus node according to the node processing capacity and credit of each consensus node, and can determine the number of pending chain transactions allocated to each consensus node according to the allocation tendency of the marked consensus node to each consensus node, thereby improving the rationality of transaction allocation, so that the pending chain transactions are allocated to the consensus nodes with good node processing capacity and high credit as much as possible, thereby improving the efficiency and security of block generation.

[0258] Detailed description of a blockchain processing method according to another embodiment of the present disclosure

[0259] In order to enable each consensus node to generate blocks in an orderly manner, reduce network congestion, and improve block generation efficiency, the blockchain processing method of the embodiment of the present disclosure is executed according to the block generation cycle.

[0260] Among them, the block generation cycle can be determined based on the number of consensus nodes, the network status of the blockchain network, etc., without any restrictions.

[0261] In one embodiment, step 340 includes:

[0262] The transactions to be put on the chain are taken out from the filtered transaction queue of the current cycle and added to the first target block to put the first target block on the chain.

[0263] The current cycle refers to the block generation cycle in which the target consensus node packages the transactions to be put on the chain into the target block to put the target block on the chain.

[0264] When this embodiment is implemented, the specific implementation process of taking out the transaction to be on-chain from the filtered transaction queue of the current cycle and adding it to the first target block is similar to the specific implementation process of taking out the transaction to be on-chain from the filtered transaction queue and adding it to the first target block in step 340 above. The difference is that this embodiment takes out the transaction to be on-chain from the filtered transaction queue of the current cycle, and compared with step 340 above, the cycle for obtaining the transaction to be on-chain is limited. To save space, it will not be repeated.

[0265] like Fig.15A As shown, the first threshold is 4, and the target consensus node first packs the pending on-chain transactions 1 and 5 in the target transaction queue into the first target block. Since the size of the first target block is still smaller than the first threshold after the target transaction queue is emptied, the target consensus node takes out pending on-chain transactions 2 and 6 from the current cycle's filtered transaction queue - pending on-chain transaction queue A and adds them to the first target block, so that the size of the first target block reaches the first threshold.

[0266] Since the previous consensus node of the target consensus node is often unable to generate blocks in time when the previous consensus node is offline or has too high a delay, in order to reduce the delay in generating blocks and improve the stability of generating blocks, the target consensus node often helps the previous consensus node to generate blocks. Based on this, the disclosed embodiment provides a solution based on the target consensus node helping the previous consensus node to generate blocks. When the previous consensus node fails to generate blocks in time, the target consensus node can package the transactions to be uploaded to the chain of the previous consensus node to reduce the delay in generating blocks and improve the efficiency and stability of generating blocks.

[0267] In one embodiment, the blockchain processing method of the embodiment of the present disclosure further includes the following steps:

[0268] In response to not receiving the consensus block to be agreed upon of the previous consensus node of the target consensus node in the previous block generation cycle, the to-be-on-chain transaction queue corresponding to the previous consensus node in multiple to-be-on-chain transaction queues is taken out and packaged into the second target block to put the second target block on the chain.

[0269] The previous block cycle refers to the block cycle in which the previous consensus node of the target consensus node packages the transactions to be put on the chain into the target block to put the target block on the chain.

[0270] The previous consensus node refers to the consensus node that packages the transactions to be uploaded into blocks and generates blocks before the target consensus node in a certain order.

[0271] A block to be consensus refers to a block that records multiple transactions to be uploaded to the chain that were packaged by the previous consensus node.

[0272] The second target block is a block used to record multiple transactions to be uploaded to the chain of the previous consensus node packaged by the target consensus node.

[0273] In the specific implementation of this embodiment, after each consensus node packages the transaction to be chained into a block in its own block cycle, it will broadcast the block to other consensus nodes for consensus. Based on this, if the previous consensus node packages the transaction to be chained into a block in the previous block cycle, it will broadcast the block to be consensus to the target consensus node for consensus. If the previous consensus node does not package the transaction to be chained into a block in time in the previous block cycle, and does not produce a block in time, then the target consensus node cannot receive the block to be consensus of the previous consensus node in the previous block cycle. Therefore, when the target consensus node does not receive the block to be consensus of the previous consensus node in the previous block cycle, in response to not receiving the block to be consensus of the previous consensus node of the target consensus node in the previous block cycle, the target consensus node will take out the transaction to be chained from the queue of transactions to be chained corresponding to the previous consensus node in multiple queues of transactions to be chained, and add it to the second target block, so as to realize the transaction chaining of the transaction to be chained of the previous consensus node.

[0274] Furthermore, in order to package all the transactions to be put on the chain of the consensus block of the previous consensus node, the size of the second target block is generally not less than the size of the consensus block. If there is still free space in the second target block after all the transactions to be put on the chain of the consensus block of the previous consensus node are packaged, the transactions to be put on the chain are taken from the filtered transaction queue of the current cycle and added to the second target block to put the second target block on the chain.

[0275] like Fig. 15B As shown, the predetermined threshold is 4. Since the previous consensus node of the target consensus node failed to generate a block in time, the target consensus node will pack the pending transactions 3, 4, 7, and 8 in the pending transaction queue corresponding to the previous consensus node into the second target block. Since the size of the second target block reaches the predetermined threshold, no more pending transactions will be added to the second target block.

[0276] Through the above method, in the embodiment of the present disclosure, when the previous consensus node fails to generate a block in time, the target consensus node packages the to-be-uploaded transactions of the previous consensus node into the second target block, thereby improving the transaction processing efficiency and stability of the blockchain network, reducing block generation delays, and improving block generation efficiency.

[0277] When the previous consensus node fails to generate a block in time, the target consensus node often helps the previous consensus node to generate a block, so as to reduce the block generation delay of the blockchain network and improve the block generation efficiency of the blockchain network. However, when the number of transactions to be uploaded to the chain of the previous consensus node is small, if the transactions to be uploaded to the chain are packaged separately into a target block, it will cause the problem of block space waste. Based on this, the embodiment of the present disclosure provides a transaction packaging scheme based on the number of transactions to be uploaded to the chain of the previous consensus node, which can better reduce the waste of block space.

[0278] Combine the following Fig.16 A detailed description of the target consensus node’s block generation process when the previous consensus node fails to generate blocks in time.

[0279] Please refer to Fig.16 In one embodiment, when the previous consensus node fails to generate a block in time, the target consensus node's block generation process includes but is not limited to the following steps 1610-1620:

[0280] Step 1610: In response to not receiving the consensus block of the previous consensus node of the target consensus node in the previous block generation cycle, taking out the transaction to be uploaded from the transaction queue to be uploaded corresponding to the previous consensus node in the multiple transaction queues to be uploaded, and adding it to the first target block;

[0281] Step 1620: If the size of the first target block is still smaller than the first threshold, in the current block generation cycle, the transactions to be chained are taken out from the filtered transaction queue and added to the first target block to chain the first target block.

[0282] Steps 1610-1620 are described in detail below.

[0283] In step 1610, in response to not receiving the consensus block of the previous consensus node of the target consensus node in the previous block generation cycle, the to-be-uploaded transaction is taken out from the to-be-uploaded transaction queue corresponding to the previous consensus node in multiple to-be-uploaded transaction queues and added to the first target block.

[0284] In the specific implementation of this embodiment, when the target consensus node has not received the block to be agreed upon of the previous consensus node in the previous block generation cycle, in response to not receiving the block to be agreed upon of the previous consensus node of the target consensus node in the previous block generation cycle, after packaging the to-be-on-chain transactions in the target transaction queue into the first target block, the to-be-on-chain transactions in the to-be-on-chain transaction queue corresponding to the previous consensus node in multiple to-be-on-chain transaction queues are taken out and added to the first target block, thereby realizing the transaction chaining of the to-be-on-chain transactions of the previous consensus node.

[0285] In step 1620, if the size of the first target block is still smaller than the first threshold, in the current block generation cycle, the transactions to be chained are taken out from the filtered transaction queue and added to the first target block to chain the first target block.

[0286] In the specific implementation of this embodiment, if the size of the first target block is still less than the first threshold after the transactions to be put on the chain in the target transaction queue and the transactions to be put on the chain that should be packed by the previous consensus node in the previous block cycle are packed into the first target block, then the transactions to be put on the chain are taken out from the filtered transaction queue and added to the first target block to put the first target block on the chain. Among them, the specific implementation process of taking out the transactions to be put on the chain from the filtered transaction queue and adding them to the first target block is similar to the specific implementation process of step 340 described above, and will not be repeated for the sake of saving space.

[0287] In addition, if the total number of transactions to be put on the chain in the target transaction queue and the transactions to be put on the chain that should be packaged by the previous consensus node in the previous block cycle is greater than the first threshold, it indicates that the first target block cannot accommodate all the transactions to be put on the chain in the target transaction queue and the transactions to be put on the chain that should be packaged by the previous consensus node in the previous block cycle. Therefore, the transactions to be put on the chain in the target transaction queue are packaged into the first target block, and then the transactions to be put on the chain are taken out from the filtered transaction queue and added to the first target block, so that the size of the first target block reaches the first threshold, and the first target block is put on the chain. Furthermore, the transactions to be put on the chain that should be packaged by the previous consensus node in the previous block cycle are packaged into the second target block.

[0288] Through the above steps 1610-1620, the embodiment of the present disclosure performs transaction packaging based on the number of pending transactions of the previous consensus node. In response to the fact that the pending consensus block of the previous consensus node of the target consensus node was not received in the previous block cycle, the pending transactions will be taken out from the pending transaction queue corresponding to the previous consensus node in the multiple pending transaction queues, and added to the first target block. In addition, according to the relationship between the size of the first target block and the first threshold, when the pending transactions of the target transaction queue are filled in the first target block and there are still vacancies for the pending transactions of the previous consensus node, the pending transactions will be taken out from the filtered transaction queue and added to the first target block, which can better reduce the waste of block space and enable the pending transactions of other consensus nodes to be packaged together into the first target block, which is conducive to improving transaction processing efficiency.

[0289] In order to make each consensus node produce blocks in order, the previous consensus node of the target consensus node is determined based on the block production order.

[0290] Please refer to Fig.17 In some embodiments, the process of determining the block order includes, but is not limited to, steps 1710-1740:

[0291] Step 1710: Collect the block status of multiple consensus nodes;

[0292] Step 1720: Determine the overall block status of the blockchain network according to the block status of multiple consensus nodes;

[0293] Step 1730: If it is determined that the overall block generation state meets the predetermined condition, the block generation order is determined to be the predetermined order;

[0294] Step 1740: If it is determined that the overall block status does not meet the predetermined conditions, the block generation order is determined based on the block status and credit of each consensus node.

[0295] Steps 1710-1740 are described in detail below.

[0296] In step 1710, the block status of multiple consensus nodes is collected.

[0297] The block status of each consensus node is used to reflect the block delay degree, node processing speed, etc. of the consensus node.

[0298] In the specific implementation of this embodiment, the block status of each consensus node can be determined by the block delay time and node processing speed of each consensus node in multiple block rounds collected on the smart contract chain.

[0299] In step 1720, the overall block production status of the blockchain network is determined based on the block production status of multiple consensus nodes.

[0300] The overall block status is used to reflect the block delay degree, node processing speed, etc. of all consensus nodes.

[0301] When this embodiment is implemented, the block status of all consensus nodes can be averaged to obtain the overall block status of the blockchain network.

[0302] For example, the average block delay of all consensus nodes is calculated to get the overall block delay of the blockchain network. The average node processing speed of all consensus nodes is calculated to get the overall processing speed of the blockchain network.

[0303] In step 1730, if it is determined that the overall block generation state meets the predetermined condition, the block generation order is determined to be a predetermined order.

[0304] The predetermined conditions are used to measure whether the overall block status is within the normal range.

[0305] In the embodiment of the present disclosure, the predetermined condition may be that the survival rate of the consensus nodes of the blockchain network is not less than a certain threshold, the overall block delay of the consensus nodes of the blockchain network is not greater than a certain threshold, etc., without limitation.

[0306] In the specific implementation of this embodiment, if the block delay time and the overall processing speed of the blockchain network reach the preset threshold, it is determined that the overall block status meets the predetermined conditions, and a block number is set for each consensus node based on actual needs. The block numbers are sorted from small to large to obtain a predetermined order, and the predetermined order is used as the block order.

[0307] In step 1740, if it is determined that the overall block status does not meet the predetermined conditions, the block generation order is determined based on the block status and credit of each consensus node.

[0308] In the specific implementation of this embodiment, if one of the block delay time and the overall processing speed of the blockchain network does not reach the preset threshold, it is determined that the overall block status does not meet the predetermined conditions, and the block order is determined based on the block status and credit of each consensus node.

[0309] The specific implementation process of determining the block generation order based on the block generation status and credit of each consensus node will be described in detail below. To save space, it will not be described here.

[0310] In other embodiments, the node survival rate of the blockchain network can also be determined based on the situation of each consensus node sending heartbeat messages, and the node survival rate is used as an evaluation indicator of whether the overall block status meets the predetermined conditions. Specifically, the total number of consensus nodes is first determined, and then the number of consensus nodes that have not sent heartbeat messages within the predetermined time period is determined, and the number of consensus nodes that have not sent heartbeat messages within the predetermined time period is divided by the total number to obtain the node survival rate. If the node survival rate is not lower than the predetermined threshold, it indicates that the overall block status meets the predetermined conditions. If the node survival rate is lower than the predetermined threshold, it indicates that the overall block status does not meet the predetermined conditions.

[0311] It should be noted that the node processing capacity and credit of each consensus node mentioned above are constantly updated, and the node processing capacity and credit of each consensus node may be different in different block production rounds. Since the overall block production status of the blockchain network will also be different in different block production rounds and different block production cycles, and the overall block production status is dynamically changing, the above block production order will be continuously updated according to the changes in the overall block production status. Whenever the overall block production status does not meet the predetermined conditions, the update mechanism is automatically triggered according to the smart contract of the blockchain, thereby triggering the update of the block production order and re-adjusting the block production order of each consensus node, wherein the updated block production order is determined based on the block production status and credit of each consensus node.

[0312] Furthermore, when the block generation order is updated, the block generation order will be recorded in the smart contract of the blockchain network, enabling all consensus nodes to access the smart contract and know the updated block generation order, so that each consensus node can reach a consensus and generate blocks in an orderly manner.

[0313] Through the above steps 1710-1740, the embodiment of the present disclosure determines the overall block state of the entire blockchain network based on the block state of each consensus node, and according to the change of the overall block state, when the overall block state meets the predetermined conditions, the predetermined order is used as the block order, so that each consensus node can generate blocks in sequence according to the predetermined order. When the overall block state changes significantly and the overall block state does not meet the predetermined conditions, the block order is dynamically updated based on the block state and credit of each consensus node, so that the consensus node with better block state and higher credit has priority to generate blocks, thereby improving the transaction processing efficiency and stability of the entire blockchain network.

[0314] Since the consensus nodes that join the blockchain network earlier often have more transactions to be uploaded, if the block generation order of each consensus node is determined arbitrarily, the consensus nodes that join the blockchain network earlier will often be ranked at the back of the block generation order, which is not conducive to the rapid block generation of this type of consensus nodes. Based on this, the embodiment of the present disclosure provides a solution for determining the predetermined order based on the network access time, which can improve the rationality of the consensus node's block generation.

[0315] Please refer to Fig.18 In some embodiments, the process of determining the predetermined order includes, but is not limited to, steps 1810-1820:

[0316] Step 1810: Obtain the time when each consensus node joins the blockchain network, and obtain the network access time of each consensus node;

[0317] Step 1820: Determine the reservation order based on the network access time.

[0318] Steps 1810-1820 are described in detail below.

[0319] In step 1810, the time when each consensus node joins the blockchain network is obtained to obtain the network access time of each consensus node.

[0320] The network entry time refers to the time when each consensus node joins the blockchain network.

[0321] When this embodiment is implemented, the time when each consensus node joins the blockchain network can be retrieved from the log data of the blockchain network, and this time can be used as the network entry time of each consensus node.

[0322] In step 1820, a predetermined order is determined based on the network access time.

[0323] In the specific implementation of this embodiment, each consensus node is sorted according to the order of network access time to obtain a predetermined order. In the predetermined order, the consensus nodes with earlier network access time are ranked in the front position, and the consensus nodes with later network access time are ranked in the back position, so that the consensus nodes with earlier network access time can generate blocks first; and the consensus nodes with later network access time can generate blocks later.

[0324] like Fig.19 As shown, the network access time of consensus node 1 is date 1, the network access time of consensus node 2 is date 2, the network access time of consensus node 3 is date 3, the network access time of consensus node 4 is date 4, the network access time of consensus node 5 is date 5, and the network access time of consensus node 6 is date 6. Among them, date 1 is earlier than date 2, date 2 is earlier than date 3, date 3 is earlier than date 4, date 4 is earlier than date 5, and date 5 is earlier than date 6. Based on this, the consensus nodes are sorted from early to late according to the network access time, and the block generation order is [consensus node 1, consensus node 2, consensus node 3, consensus node 4, consensus node 5, consensus node 6].

[0325] Through the above steps 1810-1820, the embodiment of the present disclosure determines the predetermined order according to the time when each consensus node joins the blockchain network and the order of the network access time of each consensus node, so that each consensus node generates blocks in sequence according to the network access time, which can improve the rationality of the consensus node's block generation and enable the consensus node to generate blocks in an orderly manner.

[0326] Since the block generation status and credit of the consensus node have a great impact on the block generation efficiency of the consensus node, based on this, the embodiment of the present disclosure provides a solution for determining the block generation order based on the block generation status and credit, which can improve the rationality and accuracy of the block generation order, thereby improving the overall block generation efficiency.

[0327] Please refer to Fig. 20 In some embodiments, based on the block generation status and credit of each consensus node, the process of determining the block generation order includes but is not limited to steps 2010-2040:

[0328] Step 2010: for each consensus node, determine a first score based on the block status;

[0329] Step 2020: For each consensus node, determine a second score based on the credit rating;

[0330] Step 2030: Determine the total score of each consensus node based on the weighted sum of the first score and the second score;

[0331] Step 2040: Determine the block generation order based on the total score.

[0332] Steps 2010-2040 are described in detail below.

[0333] In step 2010, for each consensus node, a first score is determined based on the block status.

[0334] In the embodiment of the present disclosure, the block generation status includes the node processing capability and the block generation delay.

[0335] The node processing capacity is used to indicate the number of pending transactions that the target block can accommodate after the consensus node packages its pending transactions into the target block in each block production round.

[0336] The block delay is used to indicate the difference between the actual block time and the scheduled block time of the consensus node.

[0337] In some embodiments, based on the block status, the process of determining the first score includes but is not limited to the following steps:

[0338] Determining a first sub-score based on the node processing capability;

[0339] Based on the block delay, determining a second sub-score;

[0340] Based on the first sub-score and the second sub-score, a first score is determined.

[0341] In the specific implementation of this embodiment, the specific implementation process of determining the first sub-score based on the node processing capacity is similar to the specific implementation process of determining the real-time score of each transaction to be on-chain based on the number of resource transfers in step 320. The difference is that the scores to be determined in the two are different and the data used are different. To save space, it will not be repeated.

[0342] The preset function used to determine the first sub-score based on the node processing capability is an increasing function with the node processing capability as the independent variable and the first sub-score as the dependent variable. The better the node processing capability, the larger the first sub-score.

[0343] Furthermore, the specific implementation process of determining the second sub-score based on the block delay is similar to the specific implementation process of determining the real-time score of each transaction to be on-chain based on the number of resource transfers in step 320. The difference is that the scores to be determined in the two are different and the data used are different. To save space, it will not be repeated.

[0344] Among them, the preset function used when determining the second sub-score based on the block delay is a decreasing function with the block delay as the independent variable and the second sub-score as the dependent variable. The larger the block delay, the smaller the second sub-score.

[0345] Furthermore, the specific implementation process of determining the first score based on the first sub-score and the second sub-score is similar to the specific implementation process of determining the allocation tendency of each other consensus node based on the first tendency and the second tendency in the above step 1330. To save space, it will not be repeated.

[0346] In step 2020, a second score is determined for each consensus node based on the credit.

[0347] In the disclosed embodiment, the credit includes transaction confirmation credit and block generation credit.

[0348] Transaction confirmation credit is used to indicate whether the consensus node produces blocks on time during consensus.

[0349] Block credibility is used to indicate the authenticity of the messages broadcast by the consensus node after the block is generated.

[0350] In some embodiments, based on the creditworthiness, the process of determining the second score includes, but is not limited to, the following steps:

[0351] Based on the transaction confirmation creditworthiness, a third sub-score is determined;

[0352] Based on the block credit, the fourth sub-score is determined;

[0353] Based on the third sub-score and the fourth sub-score, a second score is determined.

[0354] In the specific implementation of this embodiment, the specific implementation process of determining the third sub-score based on the transaction confirmation credit is similar to the specific implementation process of determining the first sub-score based on the node processing capacity described above. The difference is that the scoring objects of the two are different. The specific implementation process of determining the fourth sub-score based on the block credit is similar to the specific implementation process of determining the first sub-score based on the node processing capacity described above. The difference is that the scoring objects of the two are different. The specific implementation process of determining the second score based on the third sub-score and the fourth sub-score is similar to the specific implementation process of determining the first score based on the first sub-score and the second sub-score described above. In order to save space, it will not be repeated.

[0355] In step 2030, the total score of each consensus node is determined based on the weighted sum of the first score and the second score.

[0356] The total score is used to indicate the consensus node's priority for block generation. The larger the total score, the higher the consensus node's priority for block generation.

[0357] When this embodiment is implemented, the third weight and the fourth weight are first determined, wherein the third weight is used to indicate the importance of the block state in determining the block order, and the fourth weight is used to indicate the importance of the credit in determining the block order. Next, the third weight and the first score are multiplied to obtain a first product; the fourth weight and the second score are multiplied to obtain a second product; the first product and the second product are added to obtain an addition result, thereby achieving a weighted sum of the first score and the second score. Finally, the addition result is used as the total score of the consensus node.

[0358] It should be noted that the third weight and the fourth weight are determined according to actual needs without limitation, and the sum of the third weight and the fourth weight is 1.

[0359] In step 2040, based on the total score, the block generation order is determined.

[0360] In the specific implementation of this embodiment, the consensus nodes are sorted from high to low according to the total score to obtain the block generation order. In the block generation order, the consensus nodes with higher total scores are ranked in the front position and have priority in block generation; the consensus nodes with lower total scores are ranked in the back position.

[0361] like Fig.21 As shown in FIG. 1 , it is a schematic diagram for determining the block order in a specific scenario. There are 6 consensus nodes in the blockchain network: consensus node 1, consensus node 2, consensus node 3, consensus node 4, consensus node 5, and consensus node 6. First, for each consensus node, the evaluation information of other consensus nodes on this consensus node is collected in each block round, wherein the evaluation information includes the evaluation of the authenticity of the broadcast message of this consensus node, the timeliness of block production, etc. Next, based on the evaluation information of other consensus nodes, the block state of this consensus node is obtained. Further, based on the block state of all consensus nodes, the total block state of the blockchain network is determined. When the total block state meets the predetermined conditions, the block order is determined as [consensus node 1, consensus node 2, consensus node 3, consensus node 4, consensus node 5, consensus node 6] according to the network access time of each consensus node. When the overall block state does not meet the predetermined conditions, the total score of each consensus node is calculated according to the block state and credit of each consensus node. Among them, the total score of consensus node 1 is 70, the total score of consensus node 2 is 33, the total score of consensus node 3 is 88, the total score of consensus node 4 is 65, the total score of consensus node 5 is 73, and the total score of consensus node 6 is 90. Based on the total score, the order of block generation is determined as [consensus node 6, consensus node 3, consensus node 5, consensus node 1, consensus node 4, consensus node 2].

[0362] Through the above steps 2010-2040, the embodiment of the present disclosure determines the block generation order based on the block generation status and the credit, which can improve the rationality and accuracy of the block generation order, so that the consensus nodes with better block generation status and higher credit generation are given priority to generate blocks, thereby improving the overall block generation efficiency.

[0363] Detailed description of a process for determining a block order according to another embodiment of the present disclosure

[0364] Since the relevant information of each consensus node is often recorded in the smart contract, in addition to updating the block order according to the total node status of the blockchain network, some rules can also be set to use the node information in the smart contract to periodically update the block order. Based on this, the embodiment of the present disclosure provides a solution for periodically and automatically triggering the block order update mechanism based on the block height of the first target block, which can improve the rationality of the update of the block order and thus improve the efficiency of block production.

[0365] Please refer to Fig. 22 In some embodiments, the process of determining the block order includes but is not limited to steps 2210-2220:

[0366] Step 2210, obtaining the block height of the first target block;

[0367] Step 2220: If the block height meets the predetermined conditions, the block generation order is determined based on the block generation status and credit of each consensus node.

[0368] Steps 2210-2220 are described in detail below.

[0369] In step 2210, the block height of the first target block is obtained.

[0370] The block height is used to indicate the specific location of the first target block on the blockchain. The block height can indicate the number of blocks between the first target block and the genesis block (the first block) on the blockchain. For example, when the block height is 2, it means that the number of blocks between the first target block and the genesis block is 2.

[0371] When this embodiment is implemented specifically, the block height of the first target block can be determined based on the position of the first target block when it is linked to the blockchain.

[0372] In step 2220, if the block height meets the predetermined conditions, the block generation order is determined based on the block generation status and credit of each consensus node.

[0373] The predetermined condition is used to measure whether the block height of the first target block meets the requirement for triggering the update of the block generation order. For example, when the predetermined condition is set to a multiple of 5, the update of the block generation order is triggered.

[0374] In the specific implementation of this embodiment, if the block height of the first target block is a multiple of 5, it is determined that the block height meets the predetermined condition, the block generation order is determined based on the block generation status and credit of each consensus node, and the new block generation order is recorded in the smart contract. If the block height of the first target block is not a multiple of 5, it is determined that the block height does not meet the predetermined condition, the original block generation order is kept unchanged, and each consensus node generates blocks in sequence according to the original block generation order.

[0375] For example, when the block height of the first target block is 3 in a certain block production round, the original block production order is kept unchanged, and each consensus node produces blocks in sequence according to the original block production order; when the block height of the first target block is 5 in a certain block production round, the periodic update of the block production order is triggered, and the block production order is determined based on the block production status and credit of each consensus node, and the new block production order is recorded in the smart contract, so that each consensus node produces blocks in sequence according to the new block production order.

[0376] Furthermore, the specific implementation process of determining the block generation order based on the block generation status and credit of each consensus node is similar to the specific implementation process of the above steps 2010-2040. To save space, it will not be repeated.

[0377] Through the above steps 2210-2220, the embodiment of the present disclosure periodically and automatically triggers the block generation order update mechanism according to the block height of the first target block, and uses the block generation status and credit collected by the smart contract on the chain to adjust the block generation order, so that each consensus node can reach a consensus and adjust the block generation order openly and transparently, so that the block generation process of the consensus node can effectively respond to changes in network conditions, optimize the block generation order in real time, and improve the block generation efficiency.

[0378] Detailed description of a process for determining a block period according to an embodiment of the present disclosure

[0379] If the block generation cycle is fixed, when the network delay of the blockchain network is high or there are many transactions to be uploaded to the blockchain network, it will often cause network congestion, resulting in a decrease in block generation efficiency. Based on this, the embodiment of the present disclosure provides a solution for determining the block generation cycle based on the real-time network loading speed and the total number of transactions to be uploaded to the blockchain network, which can improve the rationality of the block generation cycle, thereby effectively avoiding network congestion, reducing block generation delay, and improving the block generation efficiency of the blockchain network.

[0380] Please refer to Fig.23 In some embodiments, the process of determining the block period includes but is not limited to steps 2310-2330:

[0381] Step 2310: Obtain the real-time loading speed of the blockchain network;

[0382] Step 2320: Determine the total number of transactions to be uploaded to the blockchain network based on the transactions to be uploaded to the blockchain in the multiple consensus nodes;

[0383] Step 2330: Determine the block generation period based on the real-time network loading speed and the total number of transactions to be uploaded to the chain.

[0384] Steps 2310-2330 are described in detail below.

[0385] In step 2310, the real-time network loading speed of the blockchain network is obtained.

[0386] The real-time network loading speed is used to reflect the number of blocks produced by consensus nodes in the blockchain network per unit time.

[0387] In the specific implementation of this embodiment, first determine the predetermined time period, then count the total number of blocks produced by the blockchain network within the predetermined time period, and finally divide the total number of blocks produced by the predetermined time period to obtain the real-time loading speed of the network.

[0388] For example, after calculation, it is found that the blockchain network generated a block every 5 milliseconds in the previous block round; and a block is generated every 1 second in the current block round. It is determined that the real-time loading speed of the blockchain network has slowed down, and it is necessary to appropriately extend the block cycle and increase the block time of each consensus node to improve the stability of block generation.

[0389] In step 2320, based on the transactions to be uploaded to the chain in multiple consensus nodes, the total number of transactions to be uploaded to the chain in the blockchain network is determined.

[0390] The total number of pending transactions is the sum of all pending transactions in the blockchain network.

[0391] In the specific implementation of this embodiment, the first total number of transactions to be on-chain for each consensus node is first determined. Then, the first total number of transactions to be on-chain for all consensus nodes is added together to obtain the total number of transactions to be on-chain for the blockchain network.

[0392] In step 2330, the block generation period is determined based on the real-time network loading speed and the total number of transactions to be uploaded to the chain.

[0393] In the specific implementation of this example, step 2330 includes but is not limited to:

[0394] Determine the third score based on the real-time network loading speed;

[0395] Determining a fourth score based on the total number of transactions to be uploaded to the chain;

[0396] Based on the third score and the fourth score, a block generation period is determined.

[0397] In the specific implementation of this embodiment, the specific implementation process of determining the third score based on the real-time network loading speed is similar to the specific implementation process of determining the first sub-score based on the node processing capacity described above. The difference is that the scoring objects of the two are different. Among them, when the real-time network loading speed is higher, the third score is higher, that is, the real-time network loading speed is faster, the network delay is smaller, and the block generation is allowed to be performed in a smaller block generation cycle to improve the block generation efficiency.

[0398] The specific implementation process of determining the fourth score based on the total number of transactions to be on-chain is similar to the specific implementation process of determining the first sub-score based on the node processing capacity mentioned above. The difference is that the scoring objects of the two are different. In order to save space, it will not be repeated. Among them, the larger the total number of transactions to be on-chain, the higher the fourth score, that is, the more transactions to be on-chain, the faster the transaction processing speed needs to be. Therefore, the block cycle needs to be shortened to improve the efficiency of block generation.

[0399] Further, when determining the block cycle based on the third score and the fourth score, first determine the fifth weight of the real-time network loading speed and the sixth weight of the total number of transactions to be on the chain, wherein the fifth weight is used to indicate the degree of influence of the real-time network loading speed on the block cycle, and the sixth weight is used to indicate the degree of influence of the total number of transactions to be on the chain on the block cycle. Next, multiply the fifth weight and the third score to obtain the third weighted score; multiply the sixth weight and the fourth score to obtain the fourth weighted score. Finally, add the third weighted score and the fourth weighted score to obtain the total score. Further, substitute the total score into the preset function, and use the output of the preset function as the block cycle, wherein the preset function is a subtracting function with the total score as the independent variable and the block cycle as the dependent variable. When the total score is larger, the block cycle is shorter. When the total score is smaller, the block cycle is longer.

[0400] It should be noted that the fifth weight and the sixth weight are determined according to actual needs without any limitation, and the sum of the fifth weight and the sixth weight is 1.

[0401] Through the above steps 2310-2330, the embodiment of the present disclosure determines the block generation cycle based on the real-time network loading speed and the total number of transactions to be chained in the blockchain network, and dynamically adjusts the block generation cycle according to the real-time network loading speed and the total number of transactions to be chained in each block generation round, so that the cycle of consensus nodes traversing other consensus nodes can be adjusted more flexibly, which can improve the rationality of the block generation cycle, so that when the network load is high and other specific circumstances, it can effectively avoid network congestion, reduce block generation delays, improve the block generation efficiency and transaction chaining efficiency of the blockchain network, and improve the performance of the entire blockchain network.

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

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

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

[0405] Fig.24 A schematic diagram of the structure of a blockchain processing device 2400 provided in an embodiment of the present disclosure. Applied to a target consensus node among multiple consensus nodes in a blockchain network, the blockchain processing device 2400 includes:

[0406] The queue acquisition unit 2410 is used to acquire multiple transaction queues to be uploaded to the chain maintained by the target consensus node, each of which stores transactions to be uploaded to the chain of one consensus node among the multiple consensus nodes;

[0407] The packaging unit 2420 is used to preferentially take out the transactions to be uploaded from the target transaction queue corresponding to the target consensus node in the multiple transaction queues to be uploaded, and package them into the first target block;

[0408] The screening unit 2430 is configured to screen out a screened transaction queue whose queue length exceeds a second threshold from the to-be-uploaded transaction queues corresponding to other consensus nodes among the plurality of consensus nodes if the size of the first target block is still smaller than the first threshold after the target transaction queue is emptied;

[0409] The supplement unit 2440 is used to take out the transactions to be chained from the filtered transaction queue and supplement them to the first target block to chain the first target block.

[0410] Optionally, the supplementing unit 2440 is specifically configured to:

[0411] For each filtered transaction queue, determine the first difference between the queue length and the second threshold, and filter out the first difference filtered transactions to be uploaded to the chain with the earliest timestamp in the filtered transaction queue;

[0412] The plurality of filtered transaction queues are first sorted in descending order of queue length, and filtered transactions to be on-chain are taken out from the filtered transaction queues according to the first sort to fill the first target block until the size of the first target block reaches a first threshold.

[0413] Optionally, the supplementing unit 2440 is specifically configured to:

[0414] For each filtered transaction queue, determine the transactions marked to be uploaded to the chain in the filtered transaction queue;

[0415] The plurality of filtered transaction queues are second-sorted in descending order of the number of marked transactions to be chained, and the marked transactions to be chained are taken out from the filtered transaction queues according to the second sorting to fill the first target block until the size of the first target block reaches the first threshold.

[0416] Optionally, the transaction to be on-chain is marked by a marking consensus node among the multiple consensus nodes in the following manner:

[0417] Obtain the second difference between the number of pending transactions on the marked consensus node and the first threshold;

[0418] The second-worst transaction with the earliest timestamp among the transactions to be put on the chain of the marked consensus node is evenly distributed to other consensus nodes, and the distributed transactions to be put on the chain are marked.

[0419] Optionally, the transaction to be on-chain is marked by a marking consensus node among the multiple consensus nodes in the following manner:

[0420] Obtain the second difference between the number of pending transactions on the marked consensus node and the first threshold;

[0421] Obtain the node processing capacity and credit of each other consensus node;

[0422] Determine the allocation preference of each other consensus node based on the node's processing capacity and credit;

[0423] The second-worst transaction to be on-chain with the earliest timestamp among the transactions to be on-chain of the marked consensus node is allocated to other consensus nodes according to the allocation tendency of each other consensus node, and the allocated transaction to be on-chain is marked.

[0424] Optionally, multiple queues of transactions to be uploaded to the chain are generated in the following way:

[0425] In response to receiving a transaction to be on-chain from a client, the transaction to be on-chain received from the client is saved in a target transaction queue corresponding to a target consensus node, and the transaction to be on-chain is forwarded to other consensus nodes;

[0426] In response to receiving transactions to be on-chain from other consensus nodes, the transactions to be on-chain received from other consensus nodes are saved in the transaction queues to be on-chain corresponding to the other consensus nodes, without forwarding the transactions to be on-chain.

[0427] Optionally, the method is executed according to a block generation cycle; the supplementing unit 2440 is used to:

[0428] Take out the transactions to be put on the chain from the filtered transaction queue of the current cycle, and add them to the first target block to put the first target block on the chain;

[0429] The blockchain processing device 2400 further includes a transaction fetching unit (not shown), which is specifically configured to:

[0430] In response to not receiving the consensus block to be agreed upon of the previous consensus node of the target consensus node in the previous block generation cycle, the to-be-on-chain transaction queue corresponding to the previous consensus node in multiple to-be-on-chain transaction queues is taken out and packaged into the second target block to put the second target block on the chain.

[0431] Optionally, the method is executed according to a block generation cycle; the supplementing unit 2440 is used to:

[0432] In response to not receiving the consensus block to be sent from the previous consensus node of the target consensus node in the previous block generation cycle, taking out the transaction to be sent from the queue of transactions to be sent corresponding to the previous consensus node in the multiple queues of transactions to be sent, and adding it to the first target block;

[0433] If the size of the first target block is still smaller than the first threshold, in the current block generation cycle, the transactions to be chained are taken out from the filtered transaction queue and added to the first target block to chain the first target block.

[0434] Optionally, the previous consensus node of the target consensus node is determined based on the block generation order, and the block generation order is determined in the following way:

[0435] A status collection unit (not shown), used to collect the block status of multiple consensus nodes;

[0436] A state determination unit (not shown), configured to determine the overall block state of the blockchain network according to the block state of multiple consensus nodes;

[0437] A first sequence determining unit (not shown), configured to determine the block generation sequence to be a predetermined sequence if it is determined that the overall block generation state satisfies a predetermined condition;

[0438] The second order determination unit (not shown) is used to determine the block generation order based on the block generation status and credit of each consensus node if it is determined that the overall block generation status does not meet the predetermined condition.

[0439] Optionally, the predetermined order is determined by:

[0440] Obtain the time when each consensus node joins the blockchain network and obtain the network access time of each consensus node;

[0441] The reservation order is determined based on the network access time.

[0442] Optionally, the second sequence determining unit (not shown) includes:

[0443] A first score determination unit (not shown), configured to determine a first score for each consensus node based on a block generation status;

[0444] A second score determination unit (not shown), configured to determine a second score for each consensus node based on the creditability;

[0445] a total score determination unit (not shown), configured to determine the total score of each consensus node based on a weighted sum of the first score and the second score;

[0446] The block generation order determination unit (not shown) is used to determine the block generation order based on the total score.

[0447] Optionally, the block status includes node processing capability and block delay; a first score determination unit (not shown) is specifically used to:

[0448] Determining a first sub-score based on the node processing capability;

[0449] Based on the block delay, determining a second sub-score;

[0450] Based on the first sub-score and the second sub-score, a first score is determined.

[0451] Optionally, the credit includes transaction confirmation credit and block generation credit; the second score determination unit (not shown) is specifically used to:

[0452] Based on the transaction confirmation creditworthiness, a third sub-score is determined;

[0453] Based on the block credit, the fourth sub-score is determined;

[0454] Based on the third sub-score and the fourth sub-score, a second score is determined.

[0455] Optionally, the block generation period is determined by:

[0456] A speed unit (not shown), used to obtain the real-time network loading speed of the blockchain network;

[0457] A transaction total number determination unit (not shown), configured to determine the total number of transactions to be uploaded to the blockchain network based on the transactions to be uploaded to the blockchain in the plurality of consensus nodes;

[0458] The cycle determination unit (not shown) is used to determine the block generation cycle based on the real-time network loading speed and the total number of transactions to be uploaded to the chain.

[0459] Optionally, the period determination unit (not shown) is specifically configured to:

[0460] Determine the third score based on the real-time network loading speed;

[0461] Determining a fourth score based on the total number of transactions to be uploaded to the chain;

[0462] Based on the third score and the fourth score, a block generation period is determined.

[0463] Optionally, the previous consensus node of the target consensus node is determined based on the block generation order, and the block generation order is determined in the following way:

[0464] Obtain the block height of the first target block;

[0465] If the block height meets the predetermined conditions, the block generation order is determined based on the block generation status and credit of each consensus node.

[0466] Reference Fig.25 , Fig.25 The structural block diagram of the terminal part of the blockchain processing method for implementing the embodiment of the present disclosure includes: Radio Frequency (RF) circuit 2510, memory 2515, input unit 2530, display unit 2540, sensor 2550, audio circuit 2560, wireless fidelity (WiFi) module 2570, processor 2580, and power supply 2590. Those skilled in the art can understand that Fig.25 The terminal structure shown does not constitute a limitation on the mobile phone or computer, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

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

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

[0469] The input unit 2530 may be used to receive input digital or character information and generate key signal input related to the setting and function control of the target terminal. Specifically, the input unit 2530 may include a touch panel 2531 and other input devices 2532.

[0470] The display unit 2540 may be used to display input information or provided information and various menus of the target terminal. The display unit 2540 may include a display panel 2541.

[0471] The audio circuit 2560, the speaker 2561, and the microphone 2562 can provide an audio interface.

[0472] In this embodiment, the processor 2580 included in the terminal can execute the blockchain processing method of the previous embodiment.

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

[0474] Fig.26 A block diagram of the structure of a portion of a server for implementing the blockchain processing method of an embodiment of the present disclosure. The server may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 2622 (e.g., one or more processors) and memory 2632, and one or more storage media 2130 (e.g., one or more mass storage devices) storing application programs 2642 or data 2644. Among them, the memory 2632 and the storage medium 2630 may be short-term storage or permanent storage. The program stored in the storage medium 2630 may include one or more modules (not shown in the figure), each of which may include a series of instruction operations on the server. Furthermore, the central processing unit 2622 may be configured to communicate with the storage medium 2630 and execute a series of instruction operations in the storage medium 2630 on the server.

[0475] The server may also include one or more power supplies 2626, one or more wired or wireless network interfaces 2650, one or more input and output interfaces 2658, and / or one or more operating systems 2641, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0476] The central processor 2622 in the server can be used to execute the blockchain processing method of the embodiment of the present disclosure.

[0477] The embodiments of the present disclosure also provide a computer-readable storage medium, which is used to store program codes, and the program codes are used to execute the blockchain processing methods of the aforementioned embodiments.

[0478] The embodiment of the present disclosure also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, so that the computer device executes and implements the above-mentioned transaction on-chain.

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

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

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

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

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

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

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

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

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

Claims

1. A blockchain processing method, characterized in that: Applied to a target consensus node among multiple consensus nodes in a blockchain network, the method comprises: Acquire multiple transaction queues to be uploaded to the chain maintained by the target consensus node, each of the transaction queues to be uploaded to the chain stores the transaction to be uploaded to the chain of one of the consensus nodes among the consensus nodes; From the target transaction queue corresponding to the target consensus node in the plurality of transaction queues to be on-chain, the transaction to be on-chain is preferentially taken out, and packaged into the first target block; If the size of the first target block is still smaller than the first threshold after the target transaction queue is empty, a filtered transaction queue whose queue length exceeds the second threshold is filtered out from the to-be-uploaded transaction queues corresponding to other consensus nodes among the plurality of consensus nodes; The transaction to be put on the chain is taken out from the filtered transaction queue and added to the first target block to put the first target block on the chain.

2. The method according to claim 1, characterized in that The taking out the to-be-uploaded transaction from the filtered transaction queue and adding it to the first target block includes: For each of the filtered transaction queues, determine a first difference between the queue length and the second threshold, and filter out the first difference filtered transactions to be uploaded to the chain with the earliest timestamp in the filtered transaction queue; The plurality of filtered transaction queues are first sorted in descending order of the queue lengths, and the filtered transactions to be on-chain are taken out from the filtered transaction queues according to the first sort to fill the first target block until the size of the first target block reaches the first threshold.

3. The method according to claim 1, characterized in that The taking out the to-be-uploaded transaction from the filtered transaction queue and adding it to the first target block includes: For each of the filtered transaction queues, determine the transactions marked to be uploaded to the chain in the filtered transaction queue; The plurality of filtered transaction queues are subjected to a second sorting in descending order of the number of the marked transactions to be chained, and the marked transactions to be chained are taken out from the filtered transaction queues according to the second sorting to fill the first target block until the size of the first target block reaches the first threshold.

4. The method according to claim 3, characterized in that The transaction marked to be on-chain is marked by a marking consensus node among the plurality of consensus nodes in the following manner: Obtaining a second difference between the number of transactions to be on-chain of the marked consensus node and the first threshold; The second difference of the transactions to be put on the chain with the earliest timestamp among the transactions to be put on the chain of the marked consensus node are evenly distributed to other consensus nodes, and the distributed transactions to be put on the chain are marked.

5. The method according to claim 3, characterized in that: The transaction marked to be on-chain is marked by a marking consensus node among the plurality of consensus nodes in the following manner: Obtaining a second difference between the number of transactions to be on-chain of the marked consensus node and the first threshold; Obtaining the node processing capacity and credit of each other consensus node; Determining the allocation tendency of each other consensus node based on the node processing capacity and the credit; The second difference transaction to be on-chain with the earliest timestamp among the transactions to be on-chain of the marked consensus node is allocated to other consensus nodes according to the allocation tendency of each other consensus node, and the allocated transaction to be on-chain is marked.

6. The method according to claim 1, characterized in that The multiple transaction queues to be uploaded are generated in the following manner: In response to receiving the transaction to be on-chain from the client, the transaction to be on-chain received from the client is saved in the target transaction queue corresponding to the target consensus node, and the transaction to be on-chain is forwarded to other consensus nodes; In response to receiving the transaction to be on-chain from the other consensus nodes, the transaction to be on-chain received from the other consensus nodes is saved in the transaction queue to be on-chain corresponding to the other consensus nodes, without forwarding the transaction to be on-chain.

7. The method according to claim 1, characterized in that The method is executed according to a block generation cycle, wherein the taking out the transaction to be put on the chain from the filtered transaction queue and adding it to the first target block to put the first target block on the chain, comprises: taking out the transaction to be put on the chain from the filtered transaction queue of the current cycle and adding it to the first target block to put the first target block on the chain; The method also includes: in response to not receiving the consensus block to be agreed upon of the previous consensus node of the target consensus node in the previous block generation cycle, taking out the transaction to be chained from the transaction to be chained queue corresponding to the previous consensus node in the plurality of transaction to be chained queues, and packaging it into a second target block, so as to chain the second target block.

8. The method according to claim 1, characterized in that The method is executed according to a block generation cycle, wherein the to-be-chained transaction is taken out from the filtered transaction queue and added to the first target block to chain the first target block, including: In response to not receiving a consensus block of a previous consensus node of the target consensus node in a previous block generation cycle, taking out the transaction to be uploaded from the transaction queue to be uploaded corresponding to the previous consensus node in the plurality of transaction queues to be uploaded, and adding it to the first target block; If the size of the first target block is still smaller than the first threshold, in the current block generation cycle, the to-be-chained transaction is taken out from the filtered transaction queue and added to the first target block to chain the first target block.

9. The method according to claim 7 or 8, characterized in that: The previous consensus node of the target consensus node is determined based on the block generation order, and the block generation order is determined in the following manner: Collecting the block status of multiple consensus nodes; Determine the overall block status of the blockchain network according to the block status of the plurality of consensus nodes; If it is determined that the overall block generation state meets a predetermined condition, the block generation order is determined to be a predetermined order; If it is determined that the overall block generation status does not meet the predetermined condition, the block generation order is determined based on the block generation status and credit of each consensus node.

10. The method according to claim 9, characterized in that The predetermined order is determined by: Obtain the time when each of the consensus nodes joins the blockchain network, and obtain the network access time of each of the consensus nodes; The predetermined order is determined based on the network access time.

11. The method according to claim 9, characterized in that The determining the block generation order based on the block generation status and credit of each of the consensus nodes includes: For each of the consensus nodes, determining a first score based on the block generation status; For each of the consensus nodes, determining a second score based on the credit; Determining a total score of each of the consensus nodes based on a weighted sum of the first score and the second score; Based on the total score, the block generation order is determined.

12. The method according to claim 11, characterized in that The block status includes node processing capacity and block delay; The determining, for each of the consensus nodes, a first score based on the block generation status includes: Determining a first sub-score based on the node processing capability; Determining a second sub-score based on the block delay; The first score is determined based on the first sub-score and the second sub-score.

13. The method according to claim 11, characterized in that The credit includes transaction confirmation credit and block generation credit; The step of determining a second score for each of the consensus nodes based on the credit level includes: Determining a third sub-score based on the transaction confirmation creditworthiness; Determining a fourth sub-score based on the block credit; The second score is determined based on the third sub-score and the fourth sub-score.

14. The method according to claim 7 or 8, characterized in that The block generation period is determined by: Obtaining the real-time network loading speed of the blockchain network; Based on the transactions to be uploaded to the blockchain in the plurality of consensus nodes, determining the total number of transactions to be uploaded to the blockchain network; The block generation period is determined based on the real-time loading speed of the network and the total number of transactions to be uploaded to the chain.

15. The method according to claim 14, characterized in that The determining the block generation period based on the real-time loading speed of the network and the total number of transactions to be uploaded to the chain comprises: Determining a third score based on the real-time network loading speed; Determining a fourth score based on the total number of transactions to be uploaded to the chain; The block generation period is determined based on the third score and the fourth score.

16. The method according to claim 7 or 8, characterized in that The previous consensus node of the target consensus node is determined based on the block generation order, and the block generation order is determined in the following manner: Obtain the block height of the first target block; If the block height meets the predetermined conditions, the block generation order is determined based on the block generation status and credit of each consensus node.

17. A blockchain processing device, characterized in that: Applied to a target consensus node among a plurality of consensus nodes in a blockchain network, the blockchain processing device comprises: A queue acquisition unit, used to acquire a plurality of to-be-online transaction queues maintained by the target consensus node, each of the to-be-online transaction queues storing the to-be-online transaction of one of the consensus nodes among the plurality of the consensus nodes; A packaging unit, used to preferentially take out the to-be-chained transaction from the target transaction queue corresponding to the target consensus node in the plurality of to-be-chained transaction queues, and package them into a first target block; A screening unit, configured to screen out a screened transaction queue whose queue length exceeds a second threshold from the to-be-uploaded transaction queues corresponding to other consensus nodes among the plurality of consensus nodes if the size of the first target block is still smaller than the first threshold after the target transaction queue is emptied; A supplement unit is used to take out the transaction to be put on the chain from the filtered transaction queue and supplement it to the first target block to put the first target block on the chain.

18. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the blockchain processing method according to any one of claims 1 to 16 is implemented.

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

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

Images