Blockchain transaction load balancing method, apparatus, device, and storage medium

Abstract

This invention provides a blockchain transaction load balancing method, apparatus, device, and storage medium. The method includes: receiving transaction requests sent by a business system and caching the transaction requests in a transaction request queue; within the current block generation cycle, retrieving transaction requests that meet a threshold condition one by one from the transaction request queue, until the end of the current block generation cycle, and submitting all transaction requests that meet the threshold condition to the blockchain node. The blockchain transaction load balancing method, apparatus, device, and storage medium provided by this invention can more accurately control the transaction load balancing of the blockchain, effectively avoiding the problem of network inaccessibility due to excessive blockchain node load.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and specifically to a blockchain transaction load balancing method, apparatus, device, and storage medium. Background Technology

[0002] In a blockchain network, a blockchain node refers to a host with autonomous processing capabilities, including mobile phones and desktop computers, which are connected to the blockchain network. When a blockchain application (i.e., a business system) initiates a transaction request, the corresponding request is sent to the blockchain node. However, due to the limited throughput of blockchain nodes, when a single blockchain node receives a large number of transaction requests, the excessive access pressure on the node can lead to transaction backlog or even system breakdown, making it impossible for the business to function normally.

[0003] To avoid excessive load on blockchain nodes, the traditional method for controlling blockchain transaction load is to use storage areas as caches for submitted transactions, thereby controlling the number of transactions sent to a single node. However, this control method is relatively simple and cannot effectively prevent network paralysis that may occur when the number of transaction requests sent to the blockchain network exceeds the network's processing capacity. Summary of the Invention

[0004] This invention provides a blockchain transaction load balancing method, apparatus, device, and storage medium to solve the technical problem that existing technologies cannot effectively prevent network paralysis caused by the amount of transaction requests sent to the blockchain network exceeding the processing capacity of the blockchain network.

[0005] In a first aspect, the present invention provides a blockchain transaction load balancing method, comprising:

[0006] Receive transaction requests sent by the business system and cache the transaction requests in the transaction request queue;

[0007] During the current block generation cycle, transaction requests that meet the threshold conditions are retrieved one by one from the transaction request queue until the current block generation cycle ends and all transaction requests that meet the threshold conditions are submitted to the blockchain node.

[0008] The transaction requests that meet the threshold conditions are determined in the following way:

[0009] If, after determining that the total number of acquired transaction requests is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of acquired transaction requests is less than or equal to the maximum total transaction size threshold corresponding to the current block generation cycle, and the total CPU resources occupied by the acquired transaction requests are less than or equal to the total CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined to be a transaction request that meets the threshold conditions.

[0010] In one embodiment, before retrieving transaction requests that meet the threshold condition one by one from the transaction request queue, the method further includes:

[0011] Obtain the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, the actual value of the total amount of CPU resources used by on-chain transactions, the predicted value of the number of on-chain transactions, the predicted value of the total size of on-chain transactions, and the predicted value of the total amount of CPU resources used by on-chain transactions within the previous block generation cycle;

[0012] Based on the time series prediction algorithm, the predicted number of on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the number of on-chain transactions in the previous block generation period; the predicted total size of on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the total size of on-chain transactions in the previous block generation period; and the predicted total CPU resources used by on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the total CPU resources used by on-chain transactions in the previous block generation period.

[0013] The predicted number of on-chain transactions within the current block generation cycle is used as the maximum transaction number threshold for the current block generation cycle. The predicted total size of on-chain transactions within the current block generation cycle is used as the maximum total transaction size threshold for the current block generation cycle. The predicted total CPU resources occupied by on-chain transactions within the current block generation cycle is used as the total CPU resources occupied by transactions for the current block generation cycle.

[0014] In one embodiment, obtaining the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, and the actual value of the total CPU resources occupied by on-chain transactions within the previous block generation cycle includes:

[0015] Get the list of transactions submitted to the blockchain and the list of transactions successfully uploaded to the blockchain during the previous block generation cycle;

[0016] Based on the list of transactions submitted to the blockchain and the list of transactions successfully uploaded to the blockchain, it is determined whether all transaction requests submitted to the blockchain during the previous block generation cycle were successfully uploaded to the blockchain.

[0017] If it is determined that all transaction requests submitted during the previous block generation period were successfully uploaded to the blockchain, then the predicted value of the number of transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the number of transactions uploaded to the blockchain during the previous block generation period, the predicted value of the total size of transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the total size of transactions uploaded to the blockchain during the previous block generation period, and the predicted value of the total amount of CPU resources occupied by transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the total amount of CPU resources occupied by transactions uploaded to the blockchain during the previous block generation period.

[0018] If it is determined that not all transaction requests submitted for on-chain processing during the previous block generation cycle were successfully processed, then the number of transactions in the list of successfully processed transactions is taken as the actual value of the number of transactions processed in the previous block generation cycle, the total number of transactions in the list of successfully processed transactions is taken as the actual value of the total size of transactions processed in the previous block generation cycle, and the total amount of CPU resources occupied by each transaction in the list of successfully processed transactions is taken as the actual value of the total amount of CPU resources occupied by transactions processed in the previous block generation cycle.

[0019] In one embodiment, the time series forecasting algorithm is exponential smoothing;

[0020] The process of obtaining the predicted number of on-chain transactions in the current block generation cycle based on the actual and predicted number of on-chain transactions in the previous block generation cycle; obtaining the predicted total size of on-chain transactions in the current block generation cycle based on the actual and predicted total size of on-chain transactions in the previous block generation cycle; and obtaining the predicted total CPU resources used by on-chain transactions in the current block generation cycle based on the actual and predicted total CPU resources used by on-chain transactions in the previous block generation cycle includes:

[0021] Determine the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient corresponding to the current block generation cycle;

[0022] Based on the first weighting coefficient, the actual value and the predicted value of the number of on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the number of on-chain transactions in the current block generation period; based on the second weighting coefficient, the actual value and the predicted value of the total size of on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the total size of on-chain transactions in the current block generation period; based on the third weighting coefficient, the actual value and the predicted value of the total amount of CPU resources occupied by on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the total amount of CPU resources occupied by on-chain transactions in the current block generation period.

[0023] In one embodiment, determining the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient corresponding to the current block generation cycle includes:

[0024] If it is determined that all transaction requests submitted for on-chain processing within the previous block generation cycle were successfully processed, then based on the first weighting coefficient and enhancement coefficient corresponding to the previous block generation cycle, the first weighting coefficient for the current block generation cycle is determined; based on the second weighting coefficient and the enhancement coefficient corresponding to the previous block generation cycle, the second weighting coefficient for the current block generation cycle is determined; based on the third weighting coefficient and the enhancement coefficient corresponding to the previous block generation cycle, the third weighting coefficient for the current block generation cycle is determined; or...

[0025] If it is determined that not all transaction requests submitted for on-chain processing during the previous block generation cycle were successfully processed, then the first weighting coefficient for the current block generation cycle is determined based on the first weighting coefficient and the decay coefficient corresponding to the previous block generation cycle; the second weighting coefficient for the current block generation cycle is determined based on the second weighting coefficient and the decay coefficient corresponding to the previous block generation cycle; and the third weighting coefficient for the current block generation cycle is determined based on the third weighting coefficient and the decay coefficient corresponding to the previous block generation cycle.

[0026] In one embodiment, the total CPU resources occupied by the acquired transaction requests are obtained in the following way:

[0027] For any acquired transaction request, based on the type of smart contract invoked by the target transaction request, determine the transaction requests that are of the same type as the smart contract invoked by the target transaction request;

[0028] Based on the CPU resources occupied by the already transacted requests, determine the CPU resources occupied by the target transacted request;

[0029] The sum of the CPU resources used by all acquired transaction requests is taken as the total CPU resources used by the acquired transaction requests.

[0030] In one embodiment, the method further includes:

[0031] The transaction requests that have not been submitted or have failed to be submitted are arranged at the head of the transaction request queue. After the current block is generated, the transaction request queue pointer is reset to the head of the transaction request queue.

[0032] Secondly, the present invention provides a blockchain transaction load balancing device, comprising:

[0033] The receiving module is used to receive transaction requests sent by the business system and cache the transaction requests in the transaction request queue;

[0034] The control module is used to retrieve transaction requests that meet the threshold conditions one by one from the transaction request queue during the current block generation cycle, and submit all transaction requests that meet the threshold conditions to the blockchain node after the current block generation cycle ends.

[0035] The transaction requests that meet the threshold conditions are determined in the following way:

[0036] If, after determining that the total number of acquired transaction requests is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of acquired transaction requests is less than or equal to the maximum total transaction size threshold corresponding to the current block generation cycle, and the total CPU resources occupied by the acquired transaction requests are less than or equal to the total CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined to be a transaction request that meets the threshold conditions.

[0037] Thirdly, the present invention provides an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the blockchain transaction load balancing method described in the first aspect.

[0038] Fourthly, the present invention provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the blockchain transaction load balancing method described in the first aspect.

[0039] The blockchain transaction load balancing method, apparatus, device, and storage medium provided by this invention control the transaction requests submitted to the blockchain nodes from three dimensions: the total number of transaction requests, the total size of transaction requests, and the total amount of CPU resources occupied by the transaction requests. This enables more accurate control of the blockchain transaction load balancing and effectively avoids the problem of network access failure due to excessive blockchain node load. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0041] Figure 1 This is a flowchart illustrating the blockchain transaction load balancing method provided by the present invention;

[0042] Figure 2 This is a schematic diagram of the structure of the blockchain transaction load balancing device provided by the present invention;

[0043] Figure 3 This is a schematic diagram of the overall architecture of the blockchain transaction load balancing device provided by the present invention;

[0044] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0046] In the current technological environment, the traditional method for controlling the transaction load of blockchain is to use the storage area as a cache for submitted transactions to control the number of transactions sent to a single node. However, the control method of the traditional method is based on a relatively single dimension and lacks handling when transaction submission fails.

[0047] To address the aforementioned issues, this invention provides a solution that aims to achieve transaction load balancing of blockchain nodes through multi-dimensional node transaction control methods, effectively handle failed transactions, prevent the loss of submitted transactions, and thus avoid the problem of the blockchain network being unable to respond effectively when there is a large amount of transaction data, thereby enabling efficient use of node resources in the blockchain.

[0048] Figure 1 This is a flowchart illustrating the blockchain transaction load balancing method provided by the present invention, as shown below. Figure 1 As shown, the method includes the following steps:

[0049] Step 100: Receive transaction requests sent by the business system and cache the transaction requests in the transaction request queue;

[0050] In this embodiment of the invention, in order to achieve efficient control of transaction load balancing of blockchain nodes, a load balancing device can be set up between the business system and the blockchain nodes. When the business system has a need for on-chain transactions, it can send the transaction request to the load balancing device, which controls the submission of the transaction request. This avoids excessive access pressure on a single blockchain node when it receives a large number of transaction requests, which could lead to transaction backlog or even breakdown, making it impossible for the business to operate normally.

[0051] Specifically, after receiving a transaction request from the business system, the load balancer can cache the transaction request in a transaction request queue. For example, the transaction request can be stored in the cache unit of the device in the form of a queue, so that the load balancer can subsequently retrieve the transaction request to be submitted to the blockchain from the transaction request queue.

[0052] Step 101: During the current block generation cycle, retrieve transaction requests that meet the threshold conditions one by one from the transaction request queue, and submit all transaction requests that meet the threshold conditions to the blockchain node after the current block generation cycle ends.

[0053] The transaction requests that meet the threshold conditions are determined in the following way:

[0054] If, after determining that the total number of acquired transaction requests is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of acquired transaction requests is less than or equal to the maximum total transaction size threshold corresponding to the current block generation cycle, and the total CPU resources occupied by the acquired transaction requests are less than or equal to the total CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined to be a transaction request that meets the threshold conditions.

[0055] Specifically, after caching the transaction requests received from the business system into the transaction request queue, the load balancer retrieves transaction requests one by one from the transaction queue at the start of the current block generation cycle. It then determines whether the transaction request meets the threshold condition. If it does, the load balancer retrieves the transaction request and continues to retrieve the next transaction request for evaluation. If it does not meet the threshold condition, the load balancer skips the transaction request (i.e., abandons retrieving the transaction request) and continues to retrieve the next transaction request for evaluation. This process continues until the current block generation cycle ends. At this point, the load balancer submits all transaction requests that meet the threshold condition to the blockchain node, which is the blockchain node to which the load balancer is connected. It can be understood that all the transaction requests that meet the threshold condition are the total number of transaction requests that the load balancer ultimately retrieves from the transaction request queue within the current block generation cycle.

[0056] It should be noted that the current block generation cycle mentioned above can be any block generation cycle, and the above method can be used to control the submission of transaction requests to blockchain nodes within any block generation cycle.

[0057] Specifically, when determining whether a transaction request meets the threshold condition, it can be determined in the following way:

[0058] During the current block generation cycle, when retrieving a transaction request from the transaction request queue, after each transaction request is retrieved, it is determined whether the total number, total size, and total CPU (Central Processing Unit) resources occupied by the retrieved transaction requests exceed the thresholds for the corresponding dimensions (i.e., total number, total size, and total CPU resources occupied). If none of the three dimensions exceed the thresholds, it indicates that retrieving the transaction request will not cause the total number, total size, and total CPU resources occupied by the retrieved transaction requests to exceed the thresholds. Submitting these retrieved transaction requests to the blockchain node will not cause excessive node load. Therefore, the transaction request meets the threshold conditions and can be submitted to the blockchain node during the current block generation cycle.

[0059] Conversely, if at least one of the three dimensions exceeds the threshold, it indicates that if the transaction request is obtained and submitted to the blockchain node along with previously obtained transaction requests, it may cause the blockchain node to be overloaded. In this case, the transaction request does not meet the threshold condition and cannot be submitted to the blockchain node in the current block generation cycle.

[0060] The blockchain transaction load balancing method provided in this invention controls the transaction requests submitted to the blockchain node from three dimensions: the total number of transaction requests, the total size of transaction requests, and the total amount of CPU resources occupied by the transaction requests. This enables more accurate control of the blockchain transaction load balancing and effectively avoids the problem of network access failure due to excessive blockchain node load.

[0061] Optionally, before retrieving transaction requests that meet the threshold condition one by one from the transaction request queue, the method further includes:

[0062] Obtain the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, the actual value of the total amount of CPU resources used by on-chain transactions, the predicted value of the number of on-chain transactions, the predicted value of the total size of on-chain transactions, and the predicted value of the total amount of CPU resources used by on-chain transactions within the previous block generation cycle;

[0063] Based on the time series prediction algorithm, the predicted number of on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the number of on-chain transactions in the previous block generation period; the predicted total size of on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the total size of on-chain transactions in the previous block generation period; and the predicted total CPU resources used by on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the total CPU resources used by on-chain transactions in the previous block generation period.

[0064] The predicted number of on-chain transactions in the current block generation cycle is used as the maximum transaction number threshold for the current block generation cycle. The predicted total size of on-chain transactions in the current block generation cycle is used as the maximum total transaction size threshold for the current block generation cycle. The predicted total CPU resources occupied by on-chain transactions in the current block generation cycle is used as the total CPU resources occupied by transactions for the current block generation cycle.

[0065] Specifically, the thresholds for the three dimensions corresponding to the current block generation cycle can be determined by predicting the number of on-chain transactions, the total size of on-chain transactions, and the total amount of CPU resources occupied by on-chain transactions within the current block generation cycle.

[0066] Based on time series prediction algorithms, by using the actual and predicted values ​​of the number of on-chain transactions, the total size of on-chain transactions, and the total amount of CPU resources used by on-chain transactions in the previous block generation cycle, the predicted values ​​of the number of on-chain transactions, the total size of on-chain transactions, and the total amount of CPU resources used by on-chain transactions in the current block generation cycle can be predicted respectively. Setting the predicted values ​​of the three dimensions corresponding to the current block generation cycle as the thresholds of the three dimensions corresponding to the current block generation cycle can more accurately control the acquisition and submission of transaction requests. This can not only achieve efficient utilization of node resources in the blockchain, but also effectively avoid excessive load on blockchain nodes, thereby achieving transaction load balancing of blockchain nodes.

[0067] Optionally, the time series forecasting algorithm can be selected according to actual needs, such as exponential smoothing, moving smoothing, differential exponential smoothing, or adaptive filtering, etc., without any restrictions.

[0068] It is understandable that the predicted values ​​for the three dimensions corresponding to the previous generation cycle can also be obtained based on time series prediction algorithms, through the actual and predicted values ​​of the number of on-chain transactions, the actual and predicted values ​​of the total size of on-chain transactions, and the actual and predicted values ​​of the total amount of CPU resources occupied by on-chain transactions in the generation cycle before the previous one.

[0069] Optionally, obtaining the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, and the actual value of the total CPU resources occupied by on-chain transactions within the previous block generation cycle includes:

[0070] Get the list of transactions submitted to the blockchain and the list of transactions successfully uploaded to the blockchain during the previous block generation cycle;

[0071] Based on the list of transactions submitted to the blockchain and the list of transactions successfully uploaded to the blockchain, it is determined whether all transaction requests submitted to the blockchain during the previous block generation cycle were successfully uploaded to the blockchain.

[0072] If it is determined that all transaction requests submitted during the previous block generation period were successfully uploaded to the blockchain, then the predicted value of the number of transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the number of transactions uploaded to the blockchain during the previous block generation period, the predicted value of the total size of transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the total size of transactions uploaded to the blockchain during the previous block generation period, and the predicted value of the total amount of CPU resources occupied by transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the total amount of CPU resources occupied by transactions uploaded to the blockchain during the previous block generation period.

[0073] If it is determined that not all transaction requests submitted for on-chain processing during the previous block generation cycle were successfully processed, then the number of transactions in the list of successfully processed transactions will be used as the actual value of the number of transactions processed in the previous block generation cycle, the total number of transactions in the list of successfully processed transactions will be used as the actual value of the total size of transactions processed in the previous block generation cycle, and the total amount of CPU resources used by each transaction in the list of successfully processed transactions will be used as the actual value of the total amount of CPU resources used by transactions processed in the previous block generation cycle.

[0074] Specifically, in order to enable the predicted thresholds for the three dimensions corresponding to the current block generation cycle to more effectively control the submission of transaction requests to blockchain nodes, it is possible to determine whether all transaction requests submitted for on-chain in the previous block generation cycle were successfully uploaded to the chain, and then determine the actual values ​​of the number of on-chain transactions, the total size of on-chain transactions, and the total amount of CPU resources occupied by on-chain transactions in the previous block generation cycle when predicting the thresholds for the three dimensions corresponding to the current block generation cycle.

[0075] Specifically, we can first obtain the list of transactions submitted to the blockchain through the load balancing device during the previous block generation cycle, as well as the list of transactions successfully uploaded to the blockchain through the same device. By comparing the contents of the two lists, we can analyze and determine whether all transaction requests in the list of transactions submitted to the blockchain during the previous block generation cycle have been successfully uploaded to the blockchain.

[0076] If so, it indicates that the transaction requests submitted during the previous block generation cycle may not have reached the load limit of the blockchain node. In this case, the predicted values ​​of the three dimensions corresponding to the previous block generation cycle can be used as the actual values ​​of the number of on-chain transactions, the actual value of the total size of on-chain transactions, and the actual value of the total amount of CPU resources occupied by on-chain transactions during the previous block generation cycle when predicting the thresholds of the three dimensions corresponding to the current block generation cycle. Instead, the actual values ​​of the total number of successfully on-chain transaction requests, the total size of on-chain transactions, and the total amount of CPU resources occupied by on-chain transactions during the previous block generation cycle should be used as the actual values ​​of the number of on-chain transactions, the actual size of on-chain transactions, and the actual value of the total amount of CPU resources occupied by on-chain transactions during the previous block generation cycle when predicting the thresholds of the three dimensions corresponding to the current block generation cycle.

[0077] If not, it indicates that the transaction requests submitted during the previous block generation cycle may have exceeded the load limit of the blockchain node. In this case, the number of transactions in the list of successfully uploaded transactions can be used as the actual value of the number of transactions uploaded during the previous block generation cycle, the total number of transactions in the list of successfully uploaded transactions can be used as the actual value of the total size of transactions uploaded during the previous block generation cycle, and the total amount of CPU resources used by each transaction in the list of successfully uploaded transactions can be used as the actual value of the total amount of CPU resources used by transactions uploaded during the previous block generation cycle.

[0078] The blockchain transaction load balancing method provided in this invention determines the actual value of the number of transactions uploaded to the chain, the actual value of the total size of transactions uploaded to the chain, and the actual value of the total amount of CPU resources occupied by transactions uploaded to the chain in the previous block generation cycle when predicting the thresholds of the three dimensions corresponding to the current block generation cycle. This allows the thresholds of the three dimensions corresponding to the current block generation cycle to more effectively control the acquisition and submission of transaction requests, thereby efficiently achieving transaction load balancing of blockchain nodes.

[0079] Optionally, the time series forecasting algorithm is exponential smoothing.

[0080] The process of obtaining the predicted number of on-chain transactions in the current block generation cycle based on the actual and predicted number of on-chain transactions in the previous block generation cycle; obtaining the predicted total size of on-chain transactions in the current block generation cycle based on the actual and predicted total size of on-chain transactions in the previous block generation cycle; and obtaining the predicted total CPU resources used by on-chain transactions in the current block generation cycle based on the actual and predicted total CPU resources used by on-chain transactions in the previous block generation cycle includes:

[0081] Determine the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient corresponding to the current block generation cycle;

[0082] Based on the first weighting coefficient, the actual value and the predicted value of the number of on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the number of on-chain transactions in the current block generation period; based on the second weighting coefficient, the actual value and the predicted value of the total size of on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the total size of on-chain transactions in the current block generation period; based on the third weighting coefficient, the actual value and the predicted value of the total amount of CPU resources used by on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the total amount of CPU resources used by on-chain transactions in the current block generation period.

[0083] Specifically, when predicting the thresholds for the three dimensions corresponding to the current block generation cycle, the exponential smoothing method can be used. Based on the first weighting coefficient, the actual value and the predicted value of the number of on-chain transactions in the previous block generation cycle are weighted and summed to obtain the predicted value of the number of on-chain transactions in the current block generation cycle. Based on the second weighting coefficient, the actual value and the predicted value of the total size of on-chain transactions in the previous block generation cycle are weighted and summed to obtain the predicted value of the total size of on-chain transactions in the current block generation cycle. Based on the third weighting coefficient, the actual value and the predicted value of the total amount of CPU resources occupied by on-chain transactions in the previous block generation cycle are weighted and summed to obtain the predicted value of the total amount of CPU resources occupied by on-chain transactions in the current block generation cycle.

[0084] The exponential smoothing method described above will be explained in detail below through specific examples.

[0085] First, the actual value n of the number of on-chain transactions in the previous generation cycle t-1. t-1 And the predicted value of on-chain transactions n pre(t-1) By performing a weighted summation, the predicted number of on-chain transactions n for the next block generation cycle t is obtained. pre(t) ; The actual value s of the total on-chain transactions during the previous generation cycle t-1. t-1 And the predicted value of the total amount of on-chain transactions s pre(t-1) By performing a weighted summation, the predicted total on-chain transaction volume s for the next block generation cycle t is obtained. pre(t) The actual value of total CPU resources c used for on-chain transactions in the previous generation cycle t-1. t-1 The predicted total CPU resources consumed by on-chain transactions, c. pre(t-1) By performing a weighted summation, the total CPU resources c predicted for on-chain transactions in the next block generation cycle t can be calculated. pre(t) As shown below:

[0086] n pre(t) =σ*n t-1 +(1–σ)*n pre(t-1) , (0 < σ < 1);

[0087] s pre(t) =δ*s t-1 +(1–δ)*s pre(t-1) , (0 < δ < 1);

[0088] c pre(t) =η*c t-1 +(1–η)*c pre(t-1) , (0 < η < 1);

[0089] Where σ, δ, and η are respectively used to calculate n pre(t) s pre(t) and cpre(t) The weighting coefficients, namely the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient, can be set to specific values ​​according to the actual situation.

[0090] n pre(t) s pre(t) and c pre(t) All predicted values ​​are obtained through exponential smoothing. The next block generates a predicted number of on-chain transactions n over period t. pre(t) For example, n pre(t) n represents the exponentially smoothed trend forecast value at time t. pre(t-1) Let n be the exponentially smoothed trend forecast value at time t-1. t-1 Let be the actual value of the total amount of data on the chain at time t-1, and σ be the weighting coefficient. Meanwhile, for n... pre(t-1) The predicted value is also obtained from the predicted value n at time t-2. pre(t-2) and actual value n t-2 The result is obtained by analogy. Assuming t∈{1,2,3,…,K}, denoted by k, then we have:

[0091]

[0092] That is, n pre(t) =σ*n t-1 +(1–σ)*σ*n t-2 +(1–σ) 2 *σ*n t-3 +…+(1–σ) K-1 *σ*n t-2-K +(1–σ) K *σ*n t-1-K ;

[0093] From this, we can see that n pre(t) These are all weighted averages of historical data from the previous k time points, with weighting coefficients of σ, σ*(1–σ), and σ*(1–σ), respectively. 2 The values, ..., follow an exponential trend, with the weight increasing as the time interval increases (e.g., closer to time t) and decreasing as the time interval decreases. Furthermore, in reality, the influence of historical data on future values ​​decreases with increasing time interval, a trend perfectly aligned with exponential smoothing. For forecasting using exponential smoothing, besides choosing an appropriate value for σ, a suitable initial value for n is also required. pre(0) When there is a large amount of historical data in the time series, the initial data has a relatively small impact on the predicted value at subsequent times. In this case, the actual value n0 at time t=0 can be selected as the predicted value. However, when there is a small amount of historical data in the time series, the average of all actual values ​​before time m can be selected as the predicted value, where m is set to 0. <m<k。

[0094] Optionally, determining the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient corresponding to the current block generation cycle includes:

[0095] If all transaction requests submitted during the previous block generation cycle were successfully uploaded to the blockchain, then the first weighting coefficient for the current block generation cycle is determined based on the first weighting coefficient and enhancement coefficient corresponding to the previous block generation cycle; the second weighting coefficient for the current block generation cycle is determined based on the second weighting coefficient and enhancement coefficient corresponding to the previous block generation cycle; and the third weighting coefficient for the current block generation cycle is determined based on the third weighting coefficient and enhancement coefficient corresponding to the previous block generation cycle; or...

[0096] If it is determined that not all transaction requests submitted for on-chain processing during the previous block generation cycle were successfully processed, then the first weighting coefficient for the current block generation cycle is determined based on the first weighting coefficient and decay coefficient corresponding to the previous block generation cycle; the second weighting coefficient for the current block generation cycle is determined based on the second weighting coefficient and decay coefficient corresponding to the previous block generation cycle; and the third weighting coefficient for the current block generation cycle is determined based on the third weighting coefficient and decay coefficient corresponding to the previous block generation cycle.

[0097] Specifically, when using the exponential smoothing method to predict the thresholds of the three dimensions corresponding to the current block generation cycle, the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient corresponding to the current block generation cycle can be determined based on whether all transaction requests submitted to the chain in the previous block generation cycle were successfully uploaded to the chain.

[0098] Taking the weighting coefficients σ, δ, and η in the above embodiment as an example, if not all transaction requests submitted during the previous block generation cycle are successfully uploaded to the blockchain, σ, δ, and η can be appropriately changed. For example, σ t =σ t-1 *(1-random(0,β)), δ t =δ t-1 *(1-random(0,β)), η t =η t-1 *(1-random(0,β)); otherwise, if all transaction requests submitted during the previous block generation period were successfully uploaded to the chain, then σ t =σ t-1 *(1+random(0,α)), δ t =δ t-1 *(1+random(0,α)), η t =η t-1 *(1+random(0,α)).

[0099] Where α represents the enhancement coefficient, β represents the attenuation coefficient, 0 < α < 1, 0 < β < 1; σt-1 and σ t These are the first weighting coefficients corresponding to the previous block generation period t-1 and the first weighting coefficients corresponding to the current block generation period t, respectively; δ t-1 and δ t These are the second weighting coefficients corresponding to the previous block generation period t-1 and the second weighting coefficients corresponding to the current block generation period t, respectively; η t-1 and η t These are the third weighting coefficients corresponding to the previous block generation period t-1 and the current block generation period t, respectively; random(0,α) means returning a random number between 0 and α, and random(0,β) means returning a random number between 0 and β.

[0100] The blockchain transaction load balancing method provided in this invention determines whether all transaction requests submitted to the chain during the previous block generation cycle have been successfully uploaded to the chain, and dynamically adjusts the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient corresponding to the current block generation cycle. This allows the predicted thresholds for the three dimensions corresponding to the current block generation cycle to more effectively control the acquisition and submission of transaction requests, thereby efficiently achieving transaction load balancing of blockchain nodes.

[0101] Optionally, the total CPU resources occupied by the acquired transaction requests are obtained in the following way:

[0102] For any acquired transaction request, based on the type of smart contract invoked by the target transaction request, determine the transaction requests that are of the same type as the smart contract invoked by the target transaction request;

[0103] Based on the CPU resources used by the already traded requests, determine the CPU resources used by the target trade request.

[0104] The sum of the CPU resources used by all acquired transaction requests is taken as the total CPU resources used by all acquired transaction requests.

[0105] Specifically, one method for predicting the CPU resources used by a transaction request in a blockchain is to use historical transaction request records of the same smart contract type. This is because the CPU resources used for calling the same method within the same smart contract are similar. For example, when submitting transaction request A in the blockchain, based on the type of smart contract called by A, we can find previously traded requests B and C, etc., with the same smart contract type as A, sorted by time in the historical records. By statistically analyzing the CPU resources used by B and C, we can predict the CPU resources used by A. For example, we can use the average of the CPU resources used by B and C as the CPU resources used by A, or we can directly use the CPU resources used by B or C as the CPU resources used by A, or other methods can be used to determine the CPU resources used by A based on the CPU resources used by B or C. There are no restrictions on this method.

[0106] It should be noted that if there are no existing transactions in the history that use the same type of smart contract as transaction request A, an initial value for CPU resources can be set for the type of smart contract called by A. This initial value can be set according to the actual situation and is not restricted here.

[0107] Optionally, the method further includes:

[0108] Uncommitted and failed transaction requests are placed at the head of the transaction request queue. After the current block is generated, the transaction request queue pointer is reset to the head of the transaction request queue.

[0109] Specifically, during the process of acquiring transaction requests that meet the threshold conditions, skipped transaction requests can be rearranged at the head of the transaction request queue. Similarly, transaction requests that actually failed to be submitted can also be rearranged at the head of the transaction request queue. After the current block is generated, the transaction request queue pointer is reset to the head of the queue. Thus, in the next block generation cycle, the skipped transaction requests and failed transaction requests in the current block generation cycle can be reacquired and submitted, avoiding the problem of transaction requests being ignored due to submission failures caused by various reasons.

[0110] The blockchain transaction load balancing device provided by the present invention is described below. The blockchain transaction load balancing device described below can be referred to in correspondence with the blockchain transaction load balancing method described above.

[0111] Figure 2 This is a schematic diagram of the structure of the blockchain transaction load balancing device provided by the present invention, as shown below. Figure 2 As shown, the device includes:

[0112] The receiving module 200 is used to receive transaction requests sent by the business system and cache the transaction requests in the transaction request queue;

[0113] The control module 210 is used to retrieve transaction requests that meet the threshold conditions one by one from the transaction request queue during the current block generation cycle, and submit all transaction requests that meet the threshold conditions to the blockchain node after the current block generation cycle ends.

[0114] The transaction requests that meet the threshold conditions are determined in the following way:

[0115] If, after determining that the total number of acquired transaction requests is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of acquired transaction requests is less than or equal to the maximum total transaction size threshold corresponding to the current block generation cycle, and the total CPU resources occupied by the acquired transaction requests are less than or equal to the total CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined to be a transaction request that meets the threshold conditions.

[0116] Optionally, the control module 210 is further configured to: obtain the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, the actual value of the total CPU resources occupied by on-chain transactions, the predicted value of the number of on-chain transactions, the predicted value of the total size of on-chain transactions, and the predicted value of the total CPU resources occupied by on-chain transactions in the previous block generation cycle; based on a time series prediction algorithm, obtain the predicted value of the number of on-chain transactions in the current block generation cycle according to the actual value and the predicted value of the number of on-chain transactions in the previous block generation cycle; and obtain the total size of on-chain transactions in the current block generation cycle according to the actual value and the predicted value of the total size of on-chain transactions in the previous block generation cycle. Size prediction: Based on the actual value of the total CPU resources occupied by on-chain transactions in the previous block generation cycle and the predicted value of the total CPU resources occupied by on-chain transactions, the predicted value of the total CPU resources occupied by on-chain transactions in the current block generation cycle is obtained; the predicted value of the number of on-chain transactions in the current block generation cycle is used as the maximum number of transactions threshold corresponding to the current block generation cycle, the predicted value of the total size of on-chain transactions in the current block generation cycle is used as the maximum total transaction size threshold corresponding to the current block generation cycle, and the predicted value of the total CPU resources occupied by on-chain transactions in the current block generation cycle is used as the total CPU resources occupied by transactions corresponding to the current block generation cycle.

[0117] Optionally, obtaining the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, and the actual value of the total CPU resources occupied by on-chain transactions in the previous block generation cycle includes: obtaining a list of transactions submitted for on-chain and a list of transactions successfully on-chain in the previous block generation cycle; based on the list of transactions submitted for on-chain and the list of transactions successfully on-chain, determining whether all transaction requests submitted for on-chain in the previous block generation cycle were successfully on-chain; if it is determined that all transaction requests submitted for on-chain in the previous block generation cycle were successfully on-chain, then the predicted value of the number of on-chain transactions in the previous block generation cycle is used as the actual value of the number of on-chain transactions in the previous block generation cycle, and the predicted value of the total size of on-chain transactions in the previous block generation cycle is used as the actual value of the number of on-chain transactions in the previous block generation cycle. The actual value of the total on-chain transaction size within the previous block generation period is used as the predicted value of the total CPU resources used by on-chain transactions within the previous block generation period. If it is determined that not all transaction requests submitted for on-chain processing within the previous block generation period were successfully processed, then the number of transactions in the list of successfully processed transactions is used as the actual value of the number of on-chain transactions within the previous block generation period, the total number of transactions in the list of successfully processed transactions is used as the actual value of the total on-chain transaction size within the previous block generation period, and the total CPU resources used by each transaction in the list of successfully processed transactions is used as the actual value of the total CPU resources used by on-chain transactions within the previous block generation period.

[0118] Optionally, the time series prediction algorithm is an exponential smoothing method; the step of obtaining the predicted number of on-chain transactions in the current block generation period based on the actual value and predicted value of the number of on-chain transactions in the previous block generation period; obtaining the predicted total size of on-chain transactions in the current block generation period based on the actual value and predicted value of the total size of on-chain transactions in the previous block generation period; and obtaining the predicted total CPU resource usage of on-chain transactions in the current block generation period based on the actual value and predicted value of the total CPU resource usage of on-chain transactions in the previous block generation period includes: determining the first weighting coefficient and the second weighting coefficient corresponding to the current block generation period respectively. The system employs a first weighting coefficient and a third weighting coefficient. Based on the first weighting coefficient, it weights and sums the actual and predicted values ​​of on-chain transactions in the previous block generation period to obtain the predicted value of on-chain transactions in the current block generation period. Based on the second weighting coefficient, it weights and sums the actual and predicted values ​​of the total size of on-chain transactions in the previous block generation period to obtain the predicted value of the total size of on-chain transactions in the current block generation period. Based on the third weighting coefficient, it weights and sums the actual and predicted values ​​of the total CPU resources used by on-chain transactions in the previous block generation period to obtain the predicted value of the total CPU resources used by on-chain transactions in the current block generation period.

[0119] Optionally, determining the first weighting coefficient, second weighting coefficient, and third weighting coefficient corresponding to the current block generation cycle includes: if it is determined that all transaction requests submitted for on-chain processing in the previous block generation cycle were successfully on-chain, then determining the first weighting coefficient corresponding to the current block generation cycle based on the first weighting coefficient and enhancement coefficient corresponding to the previous block generation cycle; determining the second weighting coefficient corresponding to the current block generation cycle based on the second weighting coefficient and enhancement coefficient corresponding to the previous block generation cycle; and determining the third weighting coefficient corresponding to the current block generation cycle based on the third weighting coefficient and enhancement coefficient corresponding to the previous block generation cycle; or, if it is determined that not all transaction requests submitted for on-chain processing in the previous block generation cycle were successfully on-chain, then determining the first weighting coefficient corresponding to the current block generation cycle based on the first weighting coefficient and decay coefficient corresponding to the previous block generation cycle; determining the second weighting coefficient corresponding to the current block generation cycle based on the second weighting coefficient and decay coefficient corresponding to the previous block generation cycle; and determining the third weighting coefficient corresponding to the current block generation cycle based on the third weighting coefficient and decay coefficient corresponding to the previous block generation cycle.

[0120] Optionally, the total CPU resources occupied by the acquired transaction requests are obtained in the following way: for any acquired transaction request, based on the type of smart contract called by the target transaction request, determine the transaction requests that are of the same type as the smart contract called by the target transaction request; based on the CPU resources occupied by the transaction requests, determine the CPU resources occupied by the target transaction request; and the sum of the CPU resources occupied by all acquired transaction requests is taken as the total CPU resources occupied by the acquired transaction requests.

[0121] Optionally, the control module 210 is further configured to: arrange unsubmitted and failed-submitted transaction requests in the transaction request queue at the head of the transaction request queue, and reset the transaction request queue pointer to the head of the transaction request queue after the current block is generated.

[0122] It should be noted that the device provided by the present invention can implement all the method steps implemented in the above method embodiments and can achieve the same technical effect. Therefore, the parts and beneficial effects that are the same as those in the method embodiments will not be described in detail here.

[0123] The above-described method and apparatus are illustrated below through specific embodiments.

[0124] Figure 3 This is a schematic diagram of the overall architecture of the blockchain transaction load balancing device provided by the present invention, as shown below. Figure 3As shown, the device is installed between the blockchain node 300 and the business system 310, and consists of several functional units, including a receiving unit 320, a caching unit 330, a control unit 340, a submission unit 350, and an acquisition unit 360. The specific descriptions of each functional unit are as follows:

[0125] (1) Receiving unit 320: used to receive transaction requests from business system 310 and send the transaction requests to cache unit 330;

[0126] (2) Cache unit 330: used to cache transaction requests submitted by business system 310;

[0127] (3) Control Unit 340: Used to control the number of transaction requests sent to blockchain node 300, and is the core unit for controlling the load balancing of transaction requests. The control unit 340 predicts and sets the transaction threshold that the node can process in the next block generation cycle based on the transaction information of the node in the previous block generation cycle obtained by the acquisition unit 360, and obtains the transaction requests within the threshold from the cache unit 330 according to the predicted threshold and sends the transaction requests to the submission unit 350;

[0128] (4) Submission unit 350: used to submit the transaction request sent by the control unit 340 to the blockchain node 300 for processing;

[0129] (5) Acquisition Unit 360: Used to acquire the total number of transactions, total transaction size and total CPU resources occupied by transactions within the generation cycle of a block on the blockchain node 300, and feed the information back to the control unit 340 for processing.

[0130] The blockchain transaction load balancing method executed by the above functional units mainly includes the following steps:

[0131] Step 1: The receiving unit 320 in the device receives the transaction request sent by the business system 310 and stores the transaction request in the form of a queue in the cache unit 330;

[0132] Step 2: The acquisition unit 360 in the device acquires the total number of transactions, the total transaction size, and the total amount of CPU resources occupied by the transactions in the previous generation cycle, and feeds this transaction information back to the control unit 340;

[0133] Step 3: The control unit 340 in the device predicts the thresholds of each dimension of the transaction content in the next generation cycle based on the feedback transaction content using a time series prediction algorithm, namely the threshold of the total number of transactions, the threshold of the total transaction size, and the threshold of the total CPU resources occupied by the transaction.

[0134] Step 4: During the current block generation cycle, the device retrieves on-chain transaction requests from the transaction request queue of the cache unit 330 and determines whether they exceed the thresholds of each dimension. If they do not exceed the thresholds, the device continues to retrieve the next transaction request. If they exceed the thresholds, the device skips the transaction request and retrieves the next transaction request in the queue until the current block is generated.

[0135] Step 5: Skipped transaction requests and actual failed transaction submission requests will be placed at the head of the queue. After the previous block is generated, the request queue pointer is reset to the head and steps 2-5 are executed in a loop.

[0136] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 4 As shown, the electronic device may include: a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 can call the computer program in the memory 430 to execute the steps of any of the blockchain transaction load balancing methods provided in the above embodiments, such as: receiving transaction requests sent by the business system and caching the transaction requests in the transaction request queue; within the current block generation cycle, retrieving transaction requests that meet the threshold conditions one by one from the transaction request queue, until the end of the current block generation cycle, and submitting all transaction requests that meet the threshold conditions to the blockchain node; wherein, the transaction requests that meet the threshold conditions are determined in the following way: if, after determining that the target transaction request is obtained, the total number of transaction requests obtained is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of the transaction requests obtained is less than or equal to the maximum total size of transactions threshold corresponding to the current block generation cycle, and the total amount of CPU resources occupied by the obtained transaction requests is less than or equal to the total amount of CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined as a transaction request that meets the threshold conditions.

[0137] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0138] On the other hand, the present invention also provides a computer program product, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, when the program instructions are executed by a computer, the computer can execute the steps of any of the blockchain transaction load balancing methods provided in the above embodiments, for example including: receiving transaction requests sent by a business system and caching the transaction requests to a transaction request queue; within the current block generation cycle, obtaining transaction requests that meet the threshold conditions one by one from the transaction request queue, until the end of the current block generation cycle time, submitting all transaction requests that meet the threshold conditions to the blockchain node; wherein, the transaction requests that meet the threshold conditions are determined in the following way: if, after determining that the target transaction request is obtained, the total number of transaction requests obtained is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of the transaction requests obtained is less than or equal to the maximum total size of transactions threshold corresponding to the current block generation cycle, and the total amount of CPU resources occupied by the obtained transaction requests is less than or equal to the total amount of CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined as a transaction request that meets the threshold conditions.

[0139] On the other hand, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps of any of the blockchain transaction load balancing methods provided in the above embodiments, for example including: receiving transaction requests sent by a business system and caching the transaction requests in a transaction request queue; within the current block generation cycle, retrieving transaction requests that meet threshold conditions one by one from the transaction request queue, until the end of the current block generation cycle, and submitting all transaction requests that meet the threshold conditions to the blockchain node; wherein, transaction requests that meet the threshold conditions are determined in the following way: if, after determining that a target transaction request has been obtained, the total number of transaction requests obtained is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of transaction requests obtained is less than or equal to the maximum total size of transactions threshold corresponding to the current block generation cycle, and the total amount of CPU resources occupied by the obtained transaction requests is less than or equal to the total amount of CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined as a transaction request that meets the threshold conditions.

[0140] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0141] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0142] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain transaction load balancing method, characterized in that, include: Receive transaction requests sent by the business system and cache the transaction requests in the transaction request queue; During the current block generation cycle, transaction requests that meet the threshold conditions are retrieved one by one from the transaction request queue until the current block generation cycle ends and all transaction requests that meet the threshold conditions are submitted to the blockchain node. The transaction requests that meet the threshold conditions are determined in the following way: If, after determining that the total number of acquired transaction requests is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of acquired transaction requests is less than or equal to the maximum total size threshold corresponding to the current block generation cycle, and the total CPU resources occupied by the acquired transaction requests are less than or equal to the total CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined to be a transaction request that meets the threshold conditions. Before retrieving transaction requests that meet the threshold condition one by one from the transaction request queue, the method further includes: Obtain the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, the actual value of the total amount of CPU resources used by on-chain transactions, the predicted value of the number of on-chain transactions, the predicted value of the total size of on-chain transactions, and the predicted value of the total amount of CPU resources used by on-chain transactions within the previous block generation cycle; Based on the time series prediction algorithm, the predicted number of on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the number of on-chain transactions in the previous block generation period; the predicted total size of on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the total size of on-chain transactions in the previous block generation period; and the predicted total CPU resources used by on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the total CPU resources used by on-chain transactions in the previous block generation period. The predicted number of on-chain transactions within the current block generation cycle is used as the maximum transaction number threshold for the current block generation cycle. The predicted total size of on-chain transactions within the current block generation cycle is used as the maximum total transaction size threshold for the current block generation cycle. The predicted total CPU resources occupied by on-chain transactions within the current block generation cycle is used as the total CPU resources occupied by transactions for the current block generation cycle.

2. The blockchain transaction load balancing method according to claim 1, characterized in that, The process of obtaining the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, and the actual value of the total CPU resources occupied by on-chain transactions within the previous block generation cycle includes: Get the list of transactions submitted to the blockchain and the list of transactions successfully uploaded to the blockchain during the previous block generation cycle; Based on the list of transactions submitted to the blockchain and the list of transactions successfully uploaded to the blockchain, it is determined whether all transaction requests submitted to the blockchain during the previous block generation cycle were successfully uploaded to the blockchain. If it is determined that all transaction requests submitted during the previous block generation period were successfully uploaded to the blockchain, then the predicted value of the number of transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the number of transactions uploaded to the blockchain during the previous block generation period, the predicted value of the total size of transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the total size of transactions uploaded to the blockchain during the previous block generation period, and the predicted value of the total amount of CPU resources occupied by transactions uploaded to the blockchain during the previous block generation period will be used as the actual value of the total amount of CPU resources occupied by transactions uploaded to the blockchain during the previous block generation period. If it is determined that not all transaction requests submitted for on-chain processing during the previous block generation cycle were successfully processed, then the number of transactions in the list of successfully processed transactions is taken as the actual value of the number of transactions processed in the previous block generation cycle, the total number of transactions in the list of successfully processed transactions is taken as the actual value of the total size of transactions processed in the previous block generation cycle, and the total amount of CPU resources occupied by each transaction in the list of successfully processed transactions is taken as the actual value of the total amount of CPU resources occupied by transactions processed in the previous block generation cycle.

3. The blockchain transaction load balancing method according to claim 2, characterized in that, The time series forecasting algorithm is exponential smoothing. The process of obtaining the predicted number of on-chain transactions in the current block generation cycle based on the actual and predicted number of on-chain transactions in the previous block generation cycle; obtaining the predicted total size of on-chain transactions in the current block generation cycle based on the actual and predicted total size of on-chain transactions in the previous block generation cycle; and obtaining the predicted total CPU resources used by on-chain transactions in the current block generation cycle based on the actual and predicted total CPU resources used by on-chain transactions in the previous block generation cycle includes: Determine the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient corresponding to the current block generation cycle; Based on the first weighting coefficient, the actual value and the predicted value of the number of on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the number of on-chain transactions in the current block generation period; based on the second weighting coefficient, the actual value and the predicted value of the total size of on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the total size of on-chain transactions in the current block generation period; based on the third weighting coefficient, the actual value and the predicted value of the total amount of CPU resources occupied by on-chain transactions in the previous block generation period are weighted and summed to obtain the predicted value of the total amount of CPU resources occupied by on-chain transactions in the current block generation period.

4. The blockchain transaction load balancing method according to claim 3, characterized in that, The determination of the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient corresponding to the current block generation cycle includes: If it is determined that all transaction requests submitted for on-chain processing within the previous block generation cycle were successfully processed, then based on the first weighting coefficient and enhancement coefficient corresponding to the previous block generation cycle, the first weighting coefficient for the current block generation cycle is determined; based on the second weighting coefficient and the enhancement coefficient corresponding to the previous block generation cycle, the second weighting coefficient for the current block generation cycle is determined; based on the third weighting coefficient and the enhancement coefficient corresponding to the previous block generation cycle, the third weighting coefficient for the current block generation cycle is determined; or... If it is determined that not all transaction requests submitted for on-chain processing during the previous block generation cycle were successfully processed, then the first weighting coefficient for the current block generation cycle is determined based on the first weighting coefficient and the decay coefficient corresponding to the previous block generation cycle; the second weighting coefficient for the current block generation cycle is determined based on the second weighting coefficient and the decay coefficient corresponding to the previous block generation cycle; and the third weighting coefficient for the current block generation cycle is determined based on the third weighting coefficient and the decay coefficient corresponding to the previous block generation cycle.

5. The blockchain transaction load balancing method according to claim 1, characterized in that, The total CPU resources used by the acquired transaction requests are obtained in the following way: For any acquired transaction request, based on the type of smart contract invoked by the target transaction request, determine the transaction requests that are of the same type as the smart contract invoked by the target transaction request; Based on the CPU resources occupied by the already transacted requests, determine the CPU resources occupied by the target transacted request; The sum of the CPU resources used by all acquired transaction requests is taken as the total CPU resources used by the acquired transaction requests.

6. The blockchain transaction load balancing method according to claim 1, characterized in that, The method further includes: The transaction requests that have not been submitted or have failed to be submitted are arranged at the head of the transaction request queue. After the current block is generated, the transaction request queue pointer is reset to the head of the transaction request queue.

7. A blockchain transaction load balancing device, characterized in that, include: The receiving module is used to receive transaction requests sent by the business system and cache the transaction requests in the transaction request queue; The control module is used to retrieve transaction requests that meet the threshold conditions one by one from the transaction request queue during the current block generation cycle, and submit all transaction requests that meet the threshold conditions to the blockchain node after the current block generation cycle ends. The transaction requests that meet the threshold conditions are determined in the following way: If, after determining that the total number of acquired transaction requests is less than or equal to the maximum number of transactions threshold corresponding to the current block generation cycle, the total size of acquired transaction requests is less than or equal to the maximum total size threshold corresponding to the current block generation cycle, and the total CPU resources occupied by the acquired transaction requests are less than or equal to the total CPU resources occupied by transactions corresponding to the current block generation cycle, then the target transaction request is determined to be a transaction request that meets the threshold conditions. The control module is also used for: Obtain the actual value of the number of on-chain transactions, the actual value of the total size of on-chain transactions, the actual value of the total amount of CPU resources used by on-chain transactions, the predicted value of the number of on-chain transactions, the predicted value of the total size of on-chain transactions, and the predicted value of the total amount of CPU resources used by on-chain transactions within the previous block generation cycle; Based on the time series prediction algorithm, the predicted number of on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the number of on-chain transactions in the previous block generation period; the predicted total size of on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the total size of on-chain transactions in the previous block generation period; and the predicted total CPU resources used by on-chain transactions in the current block generation period is obtained from the actual and predicted values ​​of the total CPU resources used by on-chain transactions in the previous block generation period. The predicted number of on-chain transactions within the current block generation cycle is used as the maximum transaction number threshold for the current block generation cycle. The predicted total size of on-chain transactions within the current block generation cycle is used as the maximum total transaction size threshold for the current block generation cycle. The predicted total CPU resources occupied by on-chain transactions within the current block generation cycle is used as the total CPU resources occupied by transactions for the current block generation cycle.

8. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the blockchain transaction load balancing method as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the blockchain transaction load balancing method as described in any one of claims 1 to 6.

Images